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Preface 


This  second  version  of  the  Department  of  Defense  (DoD)  Systems  Engineering  Plan 
(SEP)  Preparation  Guide  clarifies  the  DoD  guidance  for  systems  engineering  (SE)  planning, 
or  technical  planning,  for  acquisition  programs.  The  guide  is  separated  into  three  sections 
tailored  to  respective  milestones  and  acquisition  phases:  Milestone  A  and  Technology 
Development  (TD);  Milestone  B  and  System  Development  and  Demonstration  (SDD);  and 
Milestone  C  and  Production  and  Deployment  (PD)  /  Operations  and  Support  (O&S).  The 
guide  presents  a  sample  SEP  format  for  each  milestone  and  suggests  details  to  include  and 
sources  to  consult  for  specific  SEP  paragraphs.  This  new  version  more  clearly  outlines  the 
strategy  for  developing  a  program’s  technical  approach  and  offers  a  simplified  framework  for 
the  program  to  organize,  compile,  and  document  technical  planning. 

This  guide  is  appropriate  for  all  acquisition  category  (ACAT)  programs  and  is  applicable 
to  each  component  of  a  system:  hardware,  software,  support,  operational,  training,  and 
sustainment.  It  is  derived  from  published  government  and  industry  guidance,  standards,  and 
best  practice.  The  guidance  is  flexible  to  allow  reasonable  judgment  on  the  part  of  the 
program  to  ensure  the  SEP  is  complete. 

The  office  of  primary  responsibility  for  this  guide  is  the  Office  of  the  Deputy  Linder 
Secretary  of  Defense  for  Acquisition  and  Technology,  Systems  and  Software  Engineering, 
Enterprise  Development  (ODUSD(A&T)SSE/ED).  This  office  will  continue  to  develop  and 
coordinate  updates  to  the  guide  as  required,  based  on  any  future  policy  changes  and  customer 
feedback.  To  provide  feedback,  send  e-mail  to  ATL-ED@osd.mil. 
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Introduction 


Purpose  of  the  Systems  Engineering  Plan 

The  purpose  of  the  Systems  Engineering  Plan  (SEP)  is  to  help  programs  develop  their 
systems  engineering  (SE)  approach,  providing  a  firm  and  well-documented  technical 
foundation  for  the  program.  The  SEP  is  a  living  document  in  which  periodic  updates  capture 
the  program’s  current  status  and  evolving  SE  implementation  and  its  relationship  with  the 
overall  program  management  effort. 

The  Office  of  the  Secretary  of  Defense  (OSD)  suggests  programs  organize  the  SEP 
according  to  five  critical  focus  areas; 

•  Program  Requirements:  The  SEP  should  define  how  the  program  will  manage  all 
requirements  (statutory,  regulatory,  derived,  certification). 

•  Technical  Staffing  and  Organization  Planning:  The  SEP  should  show  how  the  program 
will  structure  and  organize  the  program  team  to  satisfy  requirements. 

•  Technical  Baseline  Management:  The  SEP  should  establish  a  technical  baseline 
approach. 

•  Technical  Review  Planning;  The  SEP  should  show  how  the  program  will  manage  the 
technical  effort,  including  the  technical  baselines,  through  event-based  technical  reviews. 

•  Integration  with  Overall  Management  of  the  Program;  The  SEP  should  link  SE  to  other 
management  efforts,  including  the  Acquisition  Strategy,  test  planning,  sustainment 
planning,  configuration  management,  risk  management,  and  life-cycle  management. 

Although  the  detailed  content  of  each  SEP  is  tailorable  according  to  the  particulars  of  a 
program  and  each  update  may  vary  depending  on  the  program’s  acquisition  phase,  using  a 
common  framework  encourages  sound  technical  planning  throughout  the  program’s  life  cycle. 
The  emphasis  should  be  on  the  rigor  of  the  technical  planning  as  captured  in  the  SEP,  not  on 
the  SEP  itself 

The  SEP  also  serves  as  a  common  reference  to  achieve  shared  stakeholder  insight 
regarding  a  program’s  planned  technical  approach.  It  provides  a  documented  understanding 
of  how  the  program  will  accommodate  cost,  schedule,  performance,  and  sustainment  trades; 
the  expected  products  of  the  SE  effort;  and  how  these  products  will  contribute  to  program 
decision  making.  Modeling  and  simulation  (M&S)  is  a  key  enabler  throughout  the  acquisition 
life  cycle;  therefore,  the  strategy  for  using  M&S  to  support  the  program  should  be 
documented  in  the  SEP  rather  than  in  a  separate  stand-alone  document. 
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Office  of  the  Secretary  of  Defense  Policy  and  Directives 

This  guide  assists  programs  to  implement  the  following  OSD  policy  directives: 

•  February  20,  2004,  USD(AT&L)  Memorandum,  “Policy  for  Systems  Engineering  in 

DoD” 

•  March  30,  2004,  Director,  Defense  Systems  Memorandum,  “Implementing  Systems 

Engineering  Plans  in  DoD-Interim  Guidance” 

•  October  22,  2004,  USD(AT&L)  Memorandum,  “Policy  Addendum  for  Systems 

Engineering.” 

The  SE  policies  established  in  these  documents  direct  that  a  SEP  shall  be  approved  by  the 
Milestone  Decision  Authority  (MDA)  in  conjunction  with  each  milestone  review  and 
integrated  with  the  Acquisition  Strategy.  The  SEP  shall  detail  the  timing,  conduct,  and 
success  criteria  for  technical  reviews. 

Policy  also  states  that  technical  reviews  shall  be  event  driven  and  conducted  when  the 
system  under  development  meets  the  review  entrance  criteria  as  documented  in  the  SEP. 

These  reviews  shall  include  participation  by  subject  matter  experts  who  are  independent  of  the 
program  unless  specifically  waived  by  the  SEP  approval  authority  and  documented  in  the 
SEP.  Policy  directs  that  each  Program  Executive  Office  (PEO)  have  a  lead  or  chief  systems 
engineer  on  staff  who  shall  review  the  PEO’s  assigned  program’s  SEP  and  oversee  the  SEP’s 
implementation. 

A  program  should  work  through  the  Systems  Engineering  Working-level  Integrated 
Product  Team  (SE  WIPE)  to  draft  and  mature  the  technical  and  management  approach 
reflected  in  the  SEP.  SE  WIPE  members  consist  of  the  program  office  lead  engineer,  the  IPX 
leads,  the  contractor  lead  systems  engineer  (when  appropriate),  the  PEO  systems  engineer,  the 
OUSD(AT&E)SSE  program  support  team  lead,  and  the  lead  system  engineers  from  the 
system  of  systems  (SoS). 

Service  Policy 

The  Services  also  publish  SE  /  SEP  policy  that  programs  should  consult: 

•  April  27,  2006,  Assistant  Secretary  of  the  Navy  (Research,  Development  and 

Acquisition)  ASN(RD&A)  Memorandum,  “Revised  Policy  for  DoN  Systems 

Engineering  Plan  (SEP)  Review  and  Approval” 

•  June  13,  2005,  Assistant  Secretary  of  the  Army  for  Acquisition,  Eogistics,  and 

Technology  ASA(AET)  Memorandum,  “Army  Systems  Engineering  Policy” 

•  October  7,  2005,  Secretary  of  the  Air  Force-Acquisition  SAF/AQ  Memorandum,  “Air 

Force  Systems  Engineering  Policy”,  Attachment  1,  and  Attachment  2 
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Suggested  SEP  Formats 

Each  program  team  should  tailor  the  SEP  contents  and  coverage  to  the  needs  and 
complexity  of  the  specific  program.  As  a  general  guideline,  use  plain  language  to  document 
the  technical  plan;  answer  the  “who,  what,  why,  when,  and  how”  questions  associated  with 
technical  planning. 

The  suggested  SEP  formats  provided  in  this  guide  include  the  preferred  title  pages  and 
coordination/approval  pages  for  ACAT  ID,  ACAT  lAM,  and  Special  Interest  Programs.  Eor 
programs  in  all  other  acquisition  categories,  components  may  supplement  SEP  guidance  and 
adapt  the  title  and  coordination  pages  in  accordance  with  direction  from  the  Component 
Acquisition  Executive  (CAE)  or  designated  SEP  approval  authority.  The  guide  includes  links 
to  related  policy  and  guidance  documents  to  provide  further  information  on  details  to  include 
in  specific  paragraphs. 

Clarification  of  Terms 

Eor  the  purposes  of  this  guide,  the  term  “system”  refers  to  the  total  of  all  components, 
including  hardware,  software,  and  human  components  as  well  as  the  operational,  sustainment, 
and  training  elements. 

The  term  “system  of  systems”  (SoS)  is  defined  as  “a  set  or  arrangement  of  systems  that 
results  when  independent  and  useful  systems  are  integrated  into  a  larger  system  that  delivers 
unique  capabilities”  (DAG  4.2.6). 

The  term  “systems  engineering”  (SE)  includes  all  specialty  domains  that  are  part  of  the  SE 
process,  including  software  engineering,  functional  engineering  (e.g.,  reliability,  safety,  and 
producibility),  and  other  engineering  specialties. 

The  term  “life  cycle”  refers  to  the  continuum  of  all  program  phases:  Concept  Refinement, 
Technology  Development,  System  Development  and  Demonstration,  Production  and 
Deployment,  and  Operations  and  Support  (sustainment). 

The  term  “key  performance  parameter”  (KPP)  refers  to  all  KPPs  and  key  system  attributes 
(KSAs)  applied  to  the  system  acquisition,  including  performance,  interoperability, 
sustainment,  safety,  or  other  KPPs/KSAs. 

SEP  Submittal  and  Approval  Instructions 

Programs  should  develop  an  initial  SEP  as  early  as  possible  during  the  Concept  Refinement 
phase.  The  technical  approach  documented  in  the  SEP  should  then  contribute  to  the 
formulation  and  update  of  the  Acquisition  Strategy  and  be  included  as  part  of  each  REP.  After 
contract  award  (i.e.,  development,  production,  or  sustainment),  the  government  program  team 
and  the  contractor(s)  should  work  jointly  to  update  the  SEP  throughout  the  program’s  life  cycle; 
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the  level  of  fidelity  and  emphasis  should  evolve  as  the  program  progresses.  For  ACAT  ID, 
ACAT  lAM,  and  Speeial  Interest  Programs,  the  programs  should  submit  all  SEPs,  draft  or 
final,  to  the  Offiee  of  the  Deputy  Under  Seeretary  of  Defense  for  Aequisition  and 
Technology,  Systems  and  Software  Engineering,  Assessments  and  Support 
(ODUSD(A&T)SSE/AS).  For  all  other  programs,  the  CAE  will  designate  the  SEP  approval 
authority  and  prescribe  submittal  instructions. 

Both  the  draft  and  the  final  SEP  shall  be  submitted  in  electronic  format.  When  the  SEP 
references  other  program  documents,  the  program  should  make  those  documents  available  to 
the  SEP  review  team  electronically  or  as  specified  by  the  CAE. 

Draft  SEP  Submittal 

•  The  program  should  prepare  the  draft  SEP  (initial  or  update)  with  the  assistance  of  an  SE 
WIPE.  Program  managers  for  ACAT  ID,  lAM,  and  Special  Interest  Programs  should 
submit  the  draft  SEP  to  ODUSD(A&T)SSE/AS  for  informal  review  and  comment  no 
later  than  120  days  before  the  applicable  milestone  decision.  Best  practice  is  to  submit 
the  draft  SEP  no  later  than  120  days  before  the  anticipated  approval  date  of  the 
Acquisition  Strategy. 

•  Upon  adjudication  of  comments  (normally  within  45  days),  the  program  should  submit 
the  final  SEP  for  formal  approval. 

Final  SEP  Submittal 

•  The  appropriate  CAE  should  submit  the  final  SEP  to  ODUSD(A&T)SSE/AS  (or 
designated  representative)  for  MDA  approval  no  later  than  30  days  before  the  milestone 
decision.  Best  practice  is  to  submit  the  SEP  no  later  than  30  days  before  the  anticipated 
approval  date  of  the  Acquisition  Strategy. 

•  Upon  adjudication  of  SEP  comments,  SSE/AS  will  forward  the  SEP  to  the  appropriate 
Overarching  Integrated  Product  Team  (OIPT)  leader  for  endorsement  to  the  MDA. 

SEP  Update  Procedures 

•  Eormal  SEP  updates  signed  by  the  MDA  are  required  for  acquisition  milestone  decisions, 
program  restructures,  and/or  program  deviations.  Updates  will  be  submitted  to 
ODUSD(A&T)SSE/AS  following  the  above  submittal  instructions. 

•  Informal  SEP  updates  should  be  approved  by  the  lead/chief  systems  engineer  and 
program  manager  before  each  technical  review. 

For  Joint  or  multiservice  programs,  the  program  will  coordinate  the  SEP  with  the 
respective  service  or  agency  chief  systems  engineer  before  submittal  to  ODUSD(A&T)SSE/AS 
Pentagon  Room  2B278. 
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Sample  Format:  Milestone  A  -  Technology  Development 


PROGRAM  NAME  -  AC  AT  LEVEL 

SYSTEMS  ENGINEERING  PLAN 
VERSION 


SUPPORTING  MILESTONE  A 
AND 

TECHNOLOGY  DEVELOPMENT 
[MONTH  DAY,  YEAR] 


OFFICE  OF  THE  SECRETARY  OE  DEEENSE  (OSD)  APPRO VAE 


Name  Date 

Under  Seeretary  of  Defense  for 
Acquisition,  Technology  and  Eogistics 


[or  designated  SEP  approval  authority] 
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Sample  Format:  Milestone  A  -  Technology  Development 


A-ii 


This  page  intentionally  left  blank. 


ODUSD(A&T)  Systems  and  Software  Engineering/Enterprise  Development 

ATE-ED@osd.mil 


Sample  Format:  Milestone  A  -  Technology  Development 


PROGRAM  NAME  -  AC  AT  LEVEL 

SYSTEMS  ENGINEERING  PLAN 
VERSION 


SUPPORTING  MILESTONE  A 
AND 

TECHNOLOGY  DEVELOPMENT 
MONTH  DAY,  YEAR 


SUBMITTED  BY 


Name 


Date  Name 


Lead  /  Chief  Systems  Engineer 


Program  Manager 


CONCURRENCE 


Name  Date 

Chief  Systems  Engineer 
(Program  Executive  Office, 

System  Center  or  Command) 


Name 

Program  Executive  Officer  or 
Equivalent 


COMPONENT  APPROVAL 


Name  Date 

Title,  Office 

Component  Acquisition  Executive 
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Sample  Format:  Milestone  A  -  Technology  Development 


1.  INTRODUCTION 

Discuss  the  purpose  of  the  SEP,  who  will  use  it,  and  how  it  will  be  used  to  define  the 
blueprint  for  the  conduct,  management,  and  eontrol  of  the  teehnical  aspects  of  the  program 
from  concept  to  disposal.  Discuss  the  commitment  to  update  the  doeument  in  the  Technology 
Development  (TD)  phase  and  throughout  the  program’s  life  cyele  to  make  it  a  living 
doeument,  and  discuss  the  plans  to  link  the  contractor’s  Systems  Engineering  Management 
Plan  (SEMP)  to  the  SEP. 

1.1,  Program  Description  and  Applicable  Documents 

Provide  a  top-level  mission  deseription  that  summarizes  the  user’s  requirements  as 
doeumented  in  the  Initial  Capabilities  Doeument  (ICD)  and/or  draft  Capability  Development 
Doeument  (CDD).  Convey  the  overall  key  elements  of  the  program,  ineluding  any  system  of 
systems  (SoS)  relationships  by  using  appropriate  DoD  Architeeture  Eramework  views  (e.g.. 
Operational  View-1)  and  supporting  narrative.  Include  a  system  description  and  a  notional 
diagram  of  the  system. 

Discuss  the  relationship  between  the  SEP  and  the  documents  developed  during  the 
Technology  Development  (TD)  phase.  Eor  example,  include  the  funding  profile;  draft 
Aequisition  Strategy;  System  Threat  Assessment  (STA);  and  Preferred  System  Coneept 
(PSC);  draft  Technology  Readiness  Assessment  (TRA);  draft  Programmatic  Environmental, 
Safety  and  Oeeupational  Health  (ESOH)  Evaluation  (PESHE);  draft  Information  Support  Plan 
(ISP);  Initial  Capabilities  Doeument  (ICD)  and  draft  Capability  Development  Doeument 
(CDD);  draft  Program  Protection  Plan  (PPP);  Risk  Management  Plan  (RMP);  Technology 
Development  Strategy  (TDS);  draft  Integrated  Master  Plan  (IMP)  and  Integrated  Master 
Schedule  (IMS);  the  Test  and  Evaluation  Strategy  (TES).  Cross-referenee  any  overarehing  or 
subordinate  SoS  program-related  SEPs.  Eist  the  points  of  eontaet  for  all  the  doeuments. 

1.2,  Current  Program  Status 

Summarize  the  overall  Aequisition  Strategy  and  how  it  is  event  driven.  Diseuss  how 
the  teehnieal  requirements  and  technieal  risks  will  be  addressed  given  program  funding  and 
sehedule  eonstraints.  Highlight  the  major  activities  that  the  program  condueted  to  date  such 
as  outcomes  of  teehnieal  reviews,  test  phases,  independent  reviews,  risk  reduction  activities, 
trade  studies,  etc. 

Discuss  how  the  Aequisition  Strategy  mitigates  technical  risks  associated  with 
technology  maturation  or  obsolescence  as  well  as  the  maturity  of  technologies  to  be  used. 
Discuss  if  any  technical  refreshes  are  planned  in  the  System  Development  and  Demonstration 
(SDD)  phase.  Highlight  the  top-level  risks  assoeiated  with  technology  and  the  risk  closure 
plans  (see  SEP  4.3,  6.3). 
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Provide  a  program  schedule  which  shows  major  milestones;  SE  technical  reviews;  and 
notional  dates  for  major  events  (developmental,  operational,  and  live  fire  test  phases; 
deliveries;  certifications;  contract  awards;  training;  site  activation,  etc.)- 

1,3,  Approach  for  SEP  Updates 

Describe  the  approach  for  updating  the  SEP  throughout  the  life  of  the  program.  Describe 
the  primary  sources  and  event  triggers  for  SEP  updates  and  include  a  change  log  tracing 
changes  to  the  original  document.  Include  a  brief  explanation  of  what  drove  the  change  (e.g., 
new  direction  or  requirements,  funding  issues,  technical  issues,  or  normal  program 
maturation,  etc.).  List  any  previous  SEP  submittals  by  date. 

2.  PROGRAM  REQUIREMENTS 

Provide  a  brief  description  of  the  program  requirements  in  support  of  the  overall  mission 
needs  and  operational  concept  as  a  basis  for  Milestone  A  and  the  TD  phase.  Include  details  as 
recommended  in  paragraphs  2. 1-2.5. 

2.1,  Capabilities,  Requirements,  and  Concept(s)  of  Operation 

Describe  the  user’s  desired  concept(s)  of  operation  (CONOPS),  capabilities,  requirements, 
and  support  approach  (see  DAG  f3,  4.2. 4.1,  4.1.3,  4.3.2). 

Consider  the  following; 

•  The  capability  gap  in  terms  of  the  missions,  tasks,  and  functions. 

•  The  linkage  between  the  desired  capabilities  and  the  CONOPS  (include  a  diagram  of  the 
CONOPS).  Reference  the  appropriate  Joint  Capabilities  Integration  and  Development 
System  (JCIDS)  documents  (e.g.,  ICD  or  Draft  CDD)  (see  CJCSM  3170. OIF;  DAG 
4.1.3). 

•  How  the  desired  capabilities  and  emerging  Key  Performance  Parameters  (KPPs)  (e.g., 
materiel  availability,  force  protection  and  net-ready)  translate  into  technical 
specifications. 

•  How  the  desired  capabilities  and  emerging  KPPs  are  linked  to  the  PSC. 

•  The  responsibilities  of  all  program  stakeholders  involved  in  the  requirements  process  and 
how  the  stakeholders  will  analyze  requirements,  conduct  trades,  resolve  conflicts  and 
reach  agreement. 

2.2,  Other  Requirements  Linked  to  the  Preferred  System  Concept 

Describe  other  requirements  linked  to  the  PSC,  including  the  following;  potential 
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statutory/regulatory,  specified/derived,  and  certification  requirements,  and  other  design 
considerations  and  constraints  (see  DAG  3.2.1,  4.1.3,  4. 3. 2.1,  4.2.4. 1,  4.3.1,  4.3.2  et  seq., 
4.4.in. 

Consider  the  following; 

•  The  program  stakeholders,  by  organization  and  position,  needed  to  endorse  the  PSC. 

•  The  statutory  and  regulatory  requirements  applicable  to  SE,  including  DoDI  5000.2, 
linked  to  the  PSC  (see  DoD  5000.2  E3.  Enclosure  3,  E4.  Enclosure  4). 

•  How  the  program  will  update  and  address  information  dependencies,  system  interfaces, 
and  interoperability  needs  from  SoS  and  external  system  dependencies  (see  SoS). 

•  The  approach  to  satisfy  requirements  (e.g.,  trade-offs  between  hardware  and  software) 
and  the  link  to  the  selection  of  critical  technologies. 

•  How  the  program  will  address  other  requirements  (specified,  derived,  and  certification) 
that  relate  to  the  PSC. 

•  How  the  program  will  develop,  define,  model,  trade,  manage,  and  test  requirements  (see 
DAG  4.5.7.2). 

•  How  the  program  will  identify,  address,  and  manage  the  full  range  of  applicable  design 
considerations  (see  DAG  4.4).  How  the  program  will  incorporate  these  design 
considerations  to  satisfy  all  requirements. 

•  How  the  architecture  products  (views,  diagrams,  descriptions,  models,  etc.)  are  related  to 
requirements  definition  as  well  as  the  functional  and  physical  architectures. 

•  The  program’s  plan  to  evaluate  product  support  capabilities  and  refine  supportability 
objectives/constraints  to  develop  the  life-cycle  sustainment  strategy. 

•  How  the  program  will  address  ESOH  considerations  in  the  TD  phase,  in  support  of  the 
entire  system  life  cycle. 

2,3,  Critical  Technologies 

Describe  the  PSC’s  critical  technologies,  including  the  enabling  technologies  required  to 
meet  program  objectives  and  requirements,  such  as  advanced  algorithms,  models, 
manufacturing,  new  designs,  operational  software,  and  support  systems,  etc.  Describe  the 
relative  risk  of  the  critical  technologies,  the  technology  maturation  required,  and  the 
limitations,  safety,  and  hazards  associated  with  these  technologies  (see  DAG  4.2.3. 1,  4.2.4. 1, 
4.3.2  et  seq.;  TRA). 

Consider  the  following; 

•  The  enabling  technologies  the  program  has  chosen  to  incorporate  in  the  PSC,  the  Critical 
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Technology  Elements  (CTEs),  and  the  currently  assessed  Technology  Readiness  Levels 
(TRLs)  for  each.  Include  the  TRLs/  MRLs  planned  at  the  conclusion  of  the  phase  and  the 
activities  necessary  to  achieve  them. 

•  The  technical  plan,  including  the  key  decision  points,  consistent  with  the  TDS,  TES,  and 
TRA,  for  managing,  maturing,  assessing,  and  integrating  all  critical  technologies. 

•  The  risk  mitigation  or  off-ramp  for  each  critical  technology,  should  a  technology  not 
mature  or  is  unsuitable  (e.g.,  have  limitations,  hazards,  etc.). 

•  The  metrics  and  tools  (modeling  and  simulation  (M&S))  used  to  track  and  assess  the 
critical  technologies  (see  DAG  4. 5. 7.2). 

2.4,  Technology  Maturation  Cost  /  Schedule  Constraints 

Describe  the  cost  and  schedule  constraints  on  the  program  and  how  these  relate  to  the 
level  of  technology  maturation  required  (see  DAG  3.2.1,  4.2.4. 1,  4.3.2). 

Consider  the  following: 

•  Technology  maturation  schedule  constraints,  underlying  key  assumptions,  schedule  risks, 
and  mitigation  approach  needed  to  mature  the  selected  technologies. 

•  Technology  maturation  cost  constraints,  underlying  key  assumptions,  cost  risks,  and 
mitigation  approach  needed  to  mature  the  selected  technologies. 

•  How  constraints  and  technology  maturations  link  to  the  program’s  technical  and 
sustainment  approach. 

2.5,  Technology  Development  and  Evolving  Acquisition  Strategy 

Describe  how  the  program  will  balance  requirements  and  CTE  maturity  trades  to  best 
meet  program  objectives  for  the  TD  phase  and  the  program’s  evolving  acquisition  strategy. 
Describe  how  success  or  failure  of  the  technology  development  will  be  reflected  in  the 
planning  for  future  phases  and  how  it  affects  desired  operational  effectiveness  and  operational 
suitability  (e.g.,  SDD)  (see  DAG  4.2.4.E  4.3.2.  4,4,  4.4.9.  5. 1.3.5.  5.2.  5.2.2.  5 .4. 1.2). 

Consider  the  following: 

•  How  the  program  will  make  design  trades  to  support  requirements  to  balance  program 
life-cycle  cost,  schedule,  performance,  sustainment,  safety,  and  risk  (see  DAG  4.5.6). 

•  Who  is  responsible  for  making  trade-off  decisions  and  at  what  level  in  the  organization 
the  decision  maker  resides. 

•  The  intended  use  of  criteria  for  decision  making  and  trade-off  of  alternative  design 
solutions  including  descriptions  of  technical  objectives,  criteria,  and  weighting  factors. 
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•  How  the  evolving  acquisition  strategy,  sustainment  plan,  and  technical  planning  for 
future  phases  will  include  off-ramps  to  adapt  to  technology  maturation  delays  or  failure 
of  CTE  maturation. 


3.  TECHNICAL  STAFFING  AND  ORGANIZATIONAL  PLANNING 

Describe  how  the  program  will  organize  and  staff  SE  activities  to  meet  the  requirements 
for  Milestone  A  and  the  TD  phase  as  outlined  in  section  2  above.  Include  details  as 
recommended  in  paragraphs  3. 1-3.5. 

3,1,  Lead/Chief  Systems  Engineer  and  Functional  Leads 

Identify  the  lead/chief  systems  engineer’s  role  and  responsibility.  Identify  the  roles  and 
responsibilities  of  the  functional  leads  (experts  outside  of  the  program  manager’s  (PM)  chain 
of  command  responsible  for  technical  processes,  products,  and  product  support).  Address  all 
elements  of  the  technology  development  across  all  elements  of  the  PSC  (operations,  support, 
and  training)  (see  DAG  4.1.6). 

Consider  the  following; 

•  The  role  and  authority  of  the  lead/chief  systems  engineer  relative  to  the  recommendation 
for  Milestone  A  entry  and  exit  criteria  and  SE  processes  and  products  (technical  reviews 
and  technical  baselines  for  each  enabling  technology). 

•  The  critical  skills  and  experience  level  required  to  fill  the  lead/chief  systems  engineer 
position. 

•  The  role  and  authority  of  the  lead/chief  systems  engineer  to  manage  external  interfaces 
and  information  support  requirements  for  SoS  (see  DAG  4.2.6;  SoS). 

•  The  types  of  functional  leads  required  to  address  the  integrated  set  of  technical 
requirements  (KPPs,  statutory,  regulatory,  specified,  certification,  and  design 
considerations). 

•  The  program’s  planned  approach  to  incorporate  appropriate  technical  authority  within 
Integrated  Product  Teams  (IPTs). 

•  The  interaction  of  the  lead/chief  systems  engineer  and  the  functional  leads  to  address  the 
total  set  of  requirements  and  technical  maturity. 

•  How  the  lead/chief  systems  engineer  and  the  functional  leads  will  interact  with  the  PM 
with  respect  to  recommendations  to  balance  cost,  schedule,  performance,  sustainment, 
and  risk  in  support  of  program  decisions. 
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3.2,  IPX  Organization/Structure 

Describe  how  the  program  will  organize  and  structure  IPTs  to  mature  enabling 
technologies  and  achieve  planned  program  outcomes  and  their  associated  CTEs.  Include  an 
organizational  chart  and  a  table  of  responsibilities  (see  DAG  4.1.5;  IPPD  Handbook). 

Consider  the  following; 

•  The  program’s  approach  for  establishing  a  product-aligned  IPX  structure. 

•  How  the  IPX  structure  will  align  with  the  program’s  products,  planned  outcomes,  and 
preliminary  Work  Breakdown  Structure  (WBS)  to  mature  critical  technologies. 

•  The  role  and  responsibility  of  each  IPX  relative  to  product  development,  management 
responsibilities  (cost,  schedule,  performance)  and  application  of  technical  and 
management  processes. 

3.3,  IPX  Staffing  /  Functional  Skills 

Describe  key  technical  staffing  requirements  for  the  entire  program,  including  IPXs. 
Identify  the  required  number  of  key  technical  positions,  critical  skills,  and  experience  levels 
necessary  to  mature  the  CTEs. 

Consider  the  following: 

•  How  the  IPTs  will  be  staffed  by  appropriate  functional  support  and  other  stakeholders 
(e.g.,  user,  technical,  sustainment,  cost,  budget,  security,  and  test)  responsible  for 
maturing  the  enabling  technologies  and  their  associated  CTEs.  Identify  their  roles  and 
responsibilities  with  regard  to  the  requirements  and  design  considerations  (see  SEP  2.1- 
2.5). 

•  The  number  and  category  of  critical  skills,  and  experience  required  to  fill  key  technical 
positions  (e.g.,  software,  design,  sustainment,  and  test  engineers). 

•  The  resources  available  to  the  IPTs,  the  staffing  plan,  and  the  current  status  of  filling  the 
key  technical  positions  for  each  IPX. 

•  The  impact  of  unfilled  positions  (e.g.,  because  of  lack  of  funding,  lack  of  experienced 
people)  and  how  the  program  will  address  vacancies. 

•  A  diagram  showing  planned  staffing  levels  by  key  program  events  (e.g.,  milestones  and 
technical  reviews).  Include  a  sand  chart  to  show  the  number  of  required  full-time 
equivalent  positions  (organic,  matrix  support  and  contractor). 

3.4,  IPX  Coordination 

Describe  how  the  program  will  integrate  and  coordinate  SE  activities  within  and  across 
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IPTs  (see  DAG  IM,  IM^). 

Consider  the  following: 

•  Specific  responsibilities  of  the  lead/chief  systems  engineer,  the  IPX  lead  engineers,  the 
SE  functional  leads,  and  the  Program  Executive  Office  Systems,  Systems  Center,  or 
Command  Chief  Engineer  and  how  these  program  participants  will  communicate  and 
coordinate. 

•  How  the  program  will  manage,  integrate,  and  control  the  IPX  structure  and  the  SE 
activities  and  products  (estimates,  assessments,  risks,  requirements,  and  technical 
baselines)  across  the  IPXs  to  support  the  maturing  and  integration  of  technologies. 

•  How  the  IPXs  will  involve  all  stakeholders  (e.g.,  users,  developers,  testers,  functional 
leads,  SMEs)  in  trade-off  and  design  consideration  analysis. 

•  Xhe  integration  of  SoS  technical  planning  with  peer  and  higher  organizations  and 
authorities  to  coordinate  design  considerations  and  trades. 

•  How  the  program  will  present  trade-off  decisions  to  adjudicate  disagreements 
among  IPXs. 

3,5,  Integration  with  Contractors  and  External  Organizations 

Describe  how  the  program  will  facilitate  interaction  among  the  SE  Working-level 
Integrated  Product  Xeam(s)  (WIPE),  other  government  organizations,  and  contractor(s)  (if 
applicable)  on  technical  tasks,  activities,  and  responsibilities  (e.g.,  requirements,  technical 
baseline,  technical  reviews).  Describe  how  the  SE  WIPE  will  document  the  technical  and 
management  approach. 

Consider  the  following: 

•  How  the  SE  WIPE  will  contribute  to  and  document  the  technical  and  management 
approach. 

•  Xhe  exit  criteria  for  the  ED  phase  and  monitoring  its  accomplishment  for  all  increments 
of  capability. 

•  Xhe  entry  and  exit  criteria  for  each  technical  review. 

•  Xhe  execution  of  the  program  in  accordance  with  an  approved  SEP. 

•  Xhe  lessons  learned  and  best  practices  throughout  DoD,  relevant  to  the  program’s 
technical  approach  and  status. 

•  How  the  program’s  organization  and  structure  will  facilitate  clear  communication  of 
technical  guidance  among  government  offices  and  all  contractors  (prime  and  subcontractors) 
engaged  in  SE  activities,  (e.g.,  requirements,  technical  baseline,  technical  reviews). 
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4.  TECHNOLOGY  MATURATION  AND  PLANNING 

Describe  the  approach  for  managing  the  overall  technical  products  and  specifications  for 
Milestone  A  and  during  the  TD  phase,  including  any  applicable  Advanced  Technology 
Demonstrations  (ATDs),  Advanced  Concept  Technology  Demonstrations  (ACTDs),  or  Joint 
Capability  Technology  Demonstrations  (JCTDs)  consistent  with  the  program’s  TDS.  Include 
details  as  recommended  in  paragraphs  4. 1-4.5. 

4.1,  Technology  Maturation  Responsibility 

Describe  who  (by  position)  will  be  responsible  for  managing  the  CTEs,  in  support  of  the 
PSC  as  they  mature,  during  the  TD  phase. 

Consider  the  following; 

•  The  role  and  responsibility  of  the  lead/chief  systems  engineer  for  maturing  the 
technologies  and  requirements  allocated  to  product  and  functional  IPTs. 

•  The  key  participants  and  their  respective  roles  to  mature  each  CTE  and  to  develop  the 
respective  technology  baseline. 

4.2,  Requirements  Traceability  and  Verification  and  Validation 

Describe  how  the  technical  baseline  approach  accounts  for  requirements  traceability  and 
requirements  verification  and  validation  (V&V)  across  the  PSC’s  technical  requirements. 

Consider  the  following: 

•  How  the  program  will  track  all  requirements  linked  to  the  PSC  (KPPs, 
statutory/regulatory,  specified/derived,  and  certification  requirements,  along  with 
verification  and  design  considerations,  etc.)  from  the  source  to  (and  throughout)  the 
system  technical  baseline  and  specification  tree. 

•  The  approach  to  ensure  there  are  no  orphan  or  childless  requirements. 

•  Who  will  conduct  requirements  traceability  and  V&V  and  what  tools  they  will  use  (e.g., 
M&S)  (see  DAG  4.5.7.2). 

•  The  plan  to  trace  and  map  all  requirements  from  initial  identification  to  the  V&V  efforts. 

•  How  the  program  will  use  technical  measures  to  determine  program  progress,  risk,  and 
status,  including  the  program’s  software  development  metrics;  technical  performance 
measures  (TPMs);  Critical  Technical  Parameters  (CTPs);  measures  of  effectiveness 
(MOEs);  measures  of  suitability  (MOSs);  measures  of  performance  (MOPs);  and 
Sustainment  KPP/KSAs  (e.g.,  materiel  availability,  materiel  reliability,  ownership  cost, 
and  mean  down  time). 
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4.3,  Technology  Maturation  and  Risk 

Describe  how  the  program  will  assess  the  results  of  each  technology  demonstration  to 
assess  technology  maturation  and  consequential  program  risk. 

Consider  the  following; 

•  How  the  program  will  demonstrate  and  assess  enabling  technology  elements  (e.g.,  TRA) 
consistent  with  the  Technology  Development  Strategy  (TDS)  and  the  TES  (see  DAG 
4.5.7.2T 

•  How  the  program  will  address  residual  technology  maturation  risk  during  the  SDD  phase. 

•  How  the  program  will  integrate  risk  management  within  the  entire  scope  of  SE  efforts 
(government  and  contractor)  to  ensure  successful  maturation  of  the  CTEs. 

•  How  the  program  will  establish  and  maintain  updated  estimates  for  software  size  and 
complexity  to  form  the  basis  of  cost  and  schedule  estimates. 

•  How  the  program  will  involve  stakeholders  in  the  assessment  of  technical  maturity. 

•  The  program’s  plan  to  establish  maturity  criteria  and  the  approach  for  application  of  these 
criteria  across  the  WBS  down  to  the  configuration  item  (Cl)  level. 

4.4,  Mapping  the  Technical  Baseline  to  the  Preferred  System  Concept 

Describe  how  results  of  the  technology  development  effort  will  map  to  the  user’s  needed 
capabilities  (ICD  to  draft  CDD),  to  the  Analysis  of  Alternatives  (AoA)  results,  and  to  the  PSC. 

Consider  the  following: 

•  The  program’s  approach  to  technical  baseline  documentation  (system,  subsystem, 
functional,  and  design  specifications  and  standards)  and  alignment  between  the  WBS  and 
the  PSC  (see  DAG  4.3.2.2) 

•  The  methods  that  show  traceability  of  KPPs  between  the  JCIDS  documents  (ICD  or  draft 
CDD)  if  available,  and  the  system  performance  specification. 

•  How  the  program  will  integrate  the  individual  technologies  to  accomplish  the  PSC. 

4.5,  Updating  and  Documenting  the  Preferred  System  Concept 

Describe  how  the  program  will  define  and  manage  the  technical  baseline,  consistent  with 
the  PSC  and  the  TDS. 

Consider  the  following: 

•  The  technical  documents  that  require  development  and  those  that  currently  exist  to 

achieve  TD  objectives  to  characterize  the  technical  baseline  (see  DAG  4.2. 3. 6, 
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4.2.3.7.4.2.3.8). 

•  The  approach  to  manage  the  technical  baseline,  accomplish  the  TRA,  and  demonstrate 
the  readiness  levels  to  achieve  Milestone  B  (TRL  6)  (see  DAG  10.5.2;  TRA). 

•  How  the  program  will  use  technical  reviews  (e.g.,  Alternative  Systems  Review  and 
System  Requirements  Review)  to  (1)  manage  technical  baselines  and  (2)  establish  system 
documentation  and  to  assess  technical  maturity  and  program  risk. 

•  The  configuration  management  (CM)  process  the  program  will  use  to  manage  the 
baselines. 

•  The  need  for  access  to  or  delivery  of  technical  data,  computer  software,  and  other 
information  for  obtaining  government  and  contractor  data  rights  that  support  program 
analysis  (M&S),  program  development  and  production  objectives,  and  proposed 
sustainment  strategy. 


5.  TECHNICAL  REVIEW  PLANNING 

Describe  the  program’s  plan  to  establish  and  conduct  event-driven  technical  reviews  (e.g.. 
Alternative  System  Review,  System  Requirements  Review,  etc.)  to  manage  and  control  the 
development  of  individual  enabling  technologies  and  their  associated  CTEs,  specifically  for 
Milestone  A  and  during  the  TD  phase  (see  DAG  4.5.8).  Include  details  as  recommended  in 
paragraphs  5. 1-5.5. 

5,1,  Event-Driven  Technical  Reviews 

Describe  the  event-driven  technical  reviews  to  be  conducted  during  the  TD  phase  at  a 
system,  subsystem,  and  enabling  technology  element  level,  as  appropriate.  Identify  program- 
specific  entry  and  exit  criteria,  defined  and  documented,  for  each  technical  review  (see  DAG 
4.2.3.3.  4.3.  4.3. 1.4.  4.3.2.4.  4.3.3.4.  4.3.3.9.  4.4.11.2.4.5.2.4.5.8).  (A  best  practice  is  to 
conduct  a  Systems  Requirements  Review  during  the  TD  phase  and  provide  the  traceability 
between  the  CDD  and  the  specification  to  bidders  in  the  Request  for  Proposal.) 

Consider  the  following; 

•  The  program’s  approach  to  executing  event-driven  technical  reviews  and  ensuring  they 

are  not  schedule  driven. 

•  The  planning  and  schedule  for  all  TD  phase  technical  reviews: 

-  The  number  of  technical  reviews  planned  and  to  what  WBS  level. 

-  The  technical  entrance/exit  criteria  for  each  review. 

-  The  approval  authority  (lead/chief  systems  engineer  and/or  functional  lead)  for 
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entry/exit  criteria  for  specific  reviews. 

•  The  timing  of  the  technical  reviews,  tied  to  the  achievement  of  entry/exit  criteria  and  the 
maturing  of  the  technical  baseline. 

•  How  the  execution  of  the  reviews  will  support  other  key  programmatic  efforts/decisions. 

5.2,  Technical  Review  Management 

Describe  who  will  be  responsible  for  overall  management  of  each  technical  review  to  be 
conducted  during  this  phase. 

Consider  the  following; 

•  The  program’s  approach  for  oversight  and  conduct  of  all  technical  reviews. 

•  The  key  OPRs  and  stakeholders  involved  in  the  technical  reviews. 

•  How  the  program  will  determine  readiness  for  technical  reviews  and  who  will  be 
responsible  for  making  the  decision  to  authorize  the  review. 

•  How  the  program  will  involve  Service-specific  technical  authority  (see  DAG  4.1.6). 

•  The  roles  and  responsibilities  of  those  involved  in  conducting  technical  reviews,  and  the 
procedures  they  will  use  to  conduct  reviews  and  to  close  outstanding  issues  from  the 
reviews. 

•  The  approach  to  ensure  that  applicable  technical  documentation  (e.g.,  hardware,  software, 
or  process  specifications)  subject  to  each  review  is  available  as  read-ahead  material  to  the 
appropriate  participants  (stakeholders  and  functional  leads). 

•  The  approach  for  integrating  outcomes  from  technical  reviews  into  the  technical  plan. 

5.3,  Chairing  of  Technical  Reviews 

Describe  how  the  program  will  select  appropriate  chair(s)  for  the  technical  reviews.  (Best 
practice  is  to  use  independent  technical  authorities.)  Describe  the  role  of  the  lead/chief 
systems  engineer. 

Consider  the  following; 

•  The  approach  for  determining  and  selecting  of  technical  review  chairs. 

•  The  roles  of  the  PM,  lead/chief  systems  engineer,  and  the  technical  review  chair  and  how 
they  will  collaborate  on  technical  reviews,  especially  the  determination  of  readiness  for 
the  review  or  audit,  and  on  reporting  of  results. 

•  How  the  program  will  ensure  that  technical  reviews  are  conducted  according  to 
established  DoD  policies  and  engineering  best  practice. 
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•  The  planned  role  of  the  PM  in  preparing  for,  executing,  and  resolving  issues  from 
technical  reviews. 

5.4,  Stakeholder  Participation  in  Technical  Reviews 

Describe  the  stakeholder  participation  in  the  technical  reviews  to  maintain  insight  to 
maturation  of  technology;  the  PSC;  the  statutory,  regulatory,  certification,  and  verification 
and  validation  (V&V)  requirements;  and  the  design  considerations  derived  from  the  PSC. 

Consider  the  following: 

•  How  appropriate  stakeholders  and  representative  offices  from  design  consideration  areas 
will  be  involved  at  key  decision  points  (e.g.,  airworthiness  certifiers  at  technical  reviews). 

•  The  program’s  plan  to  involve  stakeholders  (e.g.,  users,  testers,  safety,  certifiers,  design 
and  sustainment  engineers)  in  reviews,  by  organization. 

•  How  the  program  office,  contractor  (when  applicable)  and  relevant  industry 
representatives  will  participate  in  reviews. 

•  The  planned  membership  composition  including  the  method  for  nominating  and 
approving  the  chairperson  and  membership  for  a  technical  review  board,  if  required. 

•  How  the  program  office  will  reconcile  resource  constraints  with  technical  staffing  needs 
for  the  reviews. 

•  The  program’s  approach  to  involve  the  test  and  sustainment  communities  in  the  SE 
process  to  assess  risk  and  to  participate  in  technical  reviews  to  mature  the  technical 
baseline  (see  DoD  5000.2  E5.  Enclosure  5). 

5.5,  Peer  Participation  at  Technical  Reviews 

Describe  how  the  program  will  identify  peer  review  participants  for  each  technical  review 
(see  DoD  policy). 

Consider  the  following: 

•  The  program’s  approach  to  addressing  peer  review  in  accordance  with  DoD  policy  and 
how  peers  will  participate  in  technical  reviews. 

•  The  program’s  method  to  identify  the  subject  matter  areas  in  which  peer  insight  is  most 
relevant,  and  how  the  program  will  access  suitable  SMEs. 

•  The  planned  participation  of  senior  leadership  or  SMEs  in  functional  areas  at  major 
reviews  or  at  other  key  decision  points. 

6.  INTEGRATION  WITH  OVERALL  PROGRAM  MANAGEMENT 

Describe  the  relationship  between  SE  and  key  program  management  processes  and 
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strategies.  Describe  how  program  staff  working  in  SE  and  other  areas  will  communicate  and 
provide  information  to  support  reporting  and  milestone  requirements  during  the  TD  phase 
(see_DoDI  5000.2  E3.  Enclosure  3).  Include  details  as  recommended  in  paragraphs  6. 1-6.5. 

6.1,  Linkage  with  Other  Program  Plans 

Describe  how  the  technical  approach  will  integrate  technology  development,  requirements 
maturation,  and  overall  program  management  planning  and  control  efforts,  such  as  integrated 
master  planning  and  scheduling  (see  DAG  4.3.2,  4. 3.2. 5). 

Consider  the  following: 

•  The  program’s  approach  to  linking  and  integrating  SE  with  other  management  efforts. 

•  The  planned  process  for  incorporating  the  TD  results  into  the  SDD  planning 
documentation  (e.g.,  CDD,  AS,  PESHE,  Test  and  Evaluation  Master  Plan,  Software 
Development  Plan,  etc.). 

•  How  preliminary  producibility  analysis,  in  collaboration  with  manufacturing  engineering, 
will  influence  design  trades. 

•  How  any  required  Government  Furnished  Property  (e.g.,  test  ranges,  integration 
laboratories,  and  special  equipment)  needed  in  support  of  technology  demonstration  will 
be  included  in  the  technical  approach  and  integrated  into  the  IMP/IMS  (see  IMP/IMS; 
DAG  11.3). 

•  The  incorporation  of  technical  baselines  and  activities  across  the  WBS. 

•  The  use  of  SE  analysis  in  resource  estimation  (see  DoDI  5000.2  E6.  Enclosure  6). 

•  The  use  of  SE  (analysis  (e.g.  M&S),  technical  data  and  decisions)  to  support  other 
program  activities  and  contribute  to  key  program  documents  requiring  MDA  approval 
(see  DoDI  5000.2  E3.  Enclosure  3). 

•  The  process  for  integrating  program  protection  with  SE. 

6.2,  Use  of  Critical  Paths  and  Technical  Reviews 

Describe  how  the  program  manager,  or  equivalent,  will  use  the  critical  path  and  technical 
reviews  to  manage  the  technical  effort. 

Consider  the  following: 

•  How  the  SE  processes  and  products  are  incorporated  into  the  program  plan  and  contribute 
to  the  critical  path  during  the  TD  phase. 

•  How  the  PM  will  incorporate  findings  from  technical  reviews  into  program  decision 
making. 


ODUSD(A&T)  Systems  and  Software  Engineering/Enterprise  Development 

ATE-ED@osd.mil 


A-13 


Sample  Format:  Milestone  A  -  Technology  Development 


•  The  method  for  continuous  and  accurate  identification  and  management  of  the  critical 
path  tasks,  and  how  the  SEP  and  IMS  will  be  updated  to  maintain  alignment. 

6.3,  Risk  Management  Integration 

Describe  how  the  SE  approach  will  integrate  with  the  program’s  risk  management  (e.g., 
how  the  program  technical  reviews  will  provide  a  technical  risk  input  to  the  risk  assessment 
process)  (see  DAG  4.2.3.5.  11.4:  RM  CoP:  RMG). 

Consider  the  following; 

•  How  the  program  will  integrate  the  RMP  (including  related  SoS  RMP)  with  the  technical 
approach  and  address  life-cycle  sustainment  (see  RMG  Ch  8;  DAG  1 1.4). 

•  The  linkage  between  the  technical  reviews  and  the  program’s  risk  assessment  process 
(e.g.,  risks  of  successful  completion  of  the  next  technical  review)  (see  RMG). 

•  How  the  program  will  address  the  system  ESOH  objectives  (where  applicable)  objectives 
and  risks  as  outlined  in  MIE-STD-882D. 

•  How  the  program  will  use  metrics  in  the  risk  assessment  process. 

•  How  the  program  will  address  risks  and  issues. 

•  How  residual  risk  of  demonstrated  technologies  is  to  be  folded  into  follow-on  planning. 

•  How  software  and  SE  risks  are  linked  in  the  program  planning. 

•  A  summary  of  key  technical  risks  including  interdependencies  and  interfaces. 

6.4,  Test  and  Evaluation 

Describe  how  the  technical  approach  supporting  test  and  evaluation  (T&E)  will  integrate 
the  TES  and  V&V  efforts. 

Consider  the  following; 

•  How  V&V  plans  will  be  integrated  with  the  SE  approach. 

•  Methods  the  program  will  use  for  verification  (inspection,  analysis  (M&S), 
demonstration,  and  test)  to  ensure  T&E  assess  technology  and  requirements. 

•  The  use  of  M&S  and  prognostics  in  support  of  T&E  objectives. 

6.5,  Life-Cycle  Sustainment  Integration 

Describe  how  the  technical  approach  will  integrate  the  life-cycle  sustainment  strategy  (see 
SUP  1.3). 
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Consider  the  following: 

•  The  selected  manufacturing,  assembly,  and  test  processes  to  be  evaluated  during  TD 
hardware/software  build  and  test,  to  identify  and  validate  producibility  benefits  for  the 
future  build  of  SDD  hardware  and  software. 

•  How  the  life-cycle  sustainment  strategy  will  address  each  CTE  to  ensure  that  the 
preferred  system  solution  will  achieve  the  mandatory  sustainment  KPP/KSAs  (i.e., 
materiel  availability,  materiel  reliability,  ownership  cost,  and  mean  down  time)  (see  SUP 
1.3,  3.4;  DAG  2.3.12.  4.1.3.  5.2.2:  DoDD  5000.1). 

•  The  use  of  M&S  and  prognostics  in  support  of  life-cycle  sustainment  objectives. 

•  The  integration  of  the  life-cycle  sustainment  strategy  and  related  sustainment  plans 
within  the  overall  technical  planning. 

6,6,  Contracting  Considerations 

Describe  contracting  considerations  for  SE  (see  DAG  4.0.  4.3;  Integrating  Systems 
Engineering  into  DoD  Acquisition  Contracts). 

Consider  the  following: 

•  The  linkage  between  the  MDA-approved  SEP  and  the  contractor’s  technical  plan  to 
establish  a  fully  integrated  technical  approach. 

•  Technical  guidelines  the  program  will  incorporate  into  the  contract  to  serve  as  incentives 
for  the  contractor  to  produce  the  most  efficient  and  cost-effective  design. 

•  Award  fees  and  other  performance  incentives  to  ensure  contractors,  including  prime 
contractors  and  subcontractors,  incorporate  event-driven  reviews  and  apply  technical 
baseline  management  across  the  program,  including  among  prime  contractors  and  all 
subcontractors. 

•  How  the  program  will  integrate  SE  and  individual  enabling  technologies  and  their 
associated  CTEs  in  the  SDD  REP. 

•  How  the  program  will  assess  contractor  capability  to  conduct  life-cycle  systems  and 
software  engineering  activities  for  security  practices,  including  monitoring  for  foreign 
ownership  control  and  influence  and  protecting  Critical  Program  Information  (CPI). 
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1.  INTRODUCTION 

Discuss  the  purpose  of  the  SEP,  who  will  use  it,  and  how  the  SEP  will  be  used  to  define 
the  blueprint  for  the  conduct,  management,  and  control  of  the  technical  aspects  of  the  program 
from  development  to  disposal.  Discuss  the  commitment  to  update  the  document  in  the 
System  Development  and  Demonstration  (SDD)  phase  and  throughout  the  program’s  life 
eycle  to  make  it  a  living  doeument  and  the  plans  to  link  the  contraetor’s  Systems  Engineering 
Management  Plan  (SEMP)  to  the  SEP. 

1.1,  Program  Descriptions  and  Applicable  Documents 

Provide  a  top-level  mission  deseription  that  summarizes  the  user’s  requirements  as 
doeumented  in  the  Capability  Development  Doeument  (CDD).  Convey  the  overall  key 
elements  of  the  program,  ineluding  any  system  of  systems  (SoS)  relationships  by  using 
appropriate  DoD  Arehitecture  Eramework  views  (e.g..  Operational  View-1)  and  supporting 
narrative.  Inelude  a  system  description,  and  a  notional  diagram  of  the  system. 

Diseuss  the  relationship  between  the  SEP  and  the  doeuments  developed  during  the  System 
Development  and  Demonstration  (SDD)  phase.  Eor  example,  inelude  the  funding  profile; 
Aequisition  Strategy;  System  Threat  Assessment  (STA);  and  Preferred  System  Concept 
(PSC);  Technology  Readiness  Assessment  (TRA);  Programmatie  Environmental,  Safety  and 
Occupational  Health  (ESOH)  Evaluation  (PESHE);  Information  Support  Plan  (ISP); 
Capability  Development  Doeument  (CDD);  Program  Protection  Plan  (PPP);  Risk 
Management  Plan  (RMP);  Teehnology  Development  Strategy  (TDS);  Integrated  Master  Plan 
(IMP)  and  Integrated  Master  Sehedule  (IMS);  the  Test  and  Evaluation  Master  Plan  (TEMP). 
Cross-referenee  overarehing  or  subordinate  SoS  program-related  SEPs.  Eist  the  points  of 
eontaet  for  all  the  doeuments. 

1.2,  Current  Program  Status 

Summarize  the  overall  Acquisition  Strategy  and  how  it  is  event  driven.  Discuss  how 
the  teehnical  requirements  and  teehnieal  risks  will  be  addressed  given  the  program  funding 
and  schedule  constraints.  Highlight  the  major  aetivities  that  the  program  condueted  to  date 
such  as  outcomes  of  technical  reviews,  test  phases,  independent  reviews,  risk  reduction 
activities,  trade  studies,  ete. 

Discuss  how  the  Aequisition  Strategy  mitigates  technical  risks  associated  with 
teehnology  maturation  or  obsolescence  as  well  as  the  maturity  of  teehnologies  to  be  used. 
Diseuss  any  teehnieal  refreshes  planned  in  the  Production  and  Deployment  (PD)  and 
Operations  and  Support  (O&S)  phases.  Highlight  the  top-level  risks  assoeiated  with 
teehnology  and  the  risk  elosure  plans  (see  SEP  4.5  and  6.3) 

Provide  a  detailed  program  sehedule  showing  major  milestones;  SE  technical  reviews; 
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and  all  key  events  (  e.g.,  developmental,  operational,  and  live  fire  test  phases;  deliveries; 
eertifications;  contract  awards;  training;  site  activation,  etc.). 

1,3,  Approach  for  SEP  Updates 

Describe  the  approach  for  updating  the  SEP.  Describe  the  primary  sources  and  event 
triggers  for  updates.  Include  a  log  tracing  changes  to  the  original  document.  Include  a  brief 
explanation  of  what  drove  each  change  (e.g.,  new  direction  or  requirements,  funding  issues, 
technical  issues,  or  normal  program  maturation).  List  previous  SEP  submittals  by  date. 

2.  PROGRAM  REQUIREMENTS 

Provide  a  brief  description  of  the  program  requirements  in  support  of  the  overall  mission 
needs  and  operational  concept  as  a  basis  for  Milestone  B  and  the  SDD  phase.  Include  details 
as  recommended  in  paragraphs  2. 1-2.5. 

2.1,  Capabilities  and  Key  Performance  Parameters 

Describe  the  desired  capabilities  of  the  program,  the  traceability  of  capabilities  to  user 
needs  (Key  Performance  Parameters  (KPPs),  etc.)  and  to  lower-level  requirements,  and  the 
concept  of  operations  (CONOPS). 

Consider  the  following: 

•  In  a  diagram:  the  linkage  between  requirements  (including  lower-level  requirements)  and 
the  CONOPS.  Reference  the  appropriate  Joint  Capabilities  and  Integration  Development 
System  (JCIDS)  documents  (e.g.,  ICD,  CDD,  or  CPD)  (see  CJCSM  3170.01P;  DAG 
4.1.3). 

•  How  the  program  will  develop,  define,  model,  manage,  test,  trade,  and  track  capabilities, 
KPPs  (e.g.,  materiel  availability,  force  protection,  and  net-ready  capability),  and  other 
requirements  (see  DAG  4. 5. 7. 3). 

•  The  responsibilities  of  all  program  stakeholders  involved  in  the  requirements  process  and 
how  the  stakeholders  will  analyze  requirements,  conduct  trades,  resolve  conflicts  and 
reach  agreement. 

2.2,  Statutory  and  Regulatory  Requirements 

Describe  the  impact  of  applicable  statutory  and  regulatory  requirements  on  the  system’s 
design.  If  unknown,  describe  the  approach  for  understanding  the  potential  impact  of  these 
requirements  on  the  design. 
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Consider  the  following: 

•  The  statutory  and  regulatory  requirements,  including  DoDI  5000.2,  that  are  applicable  to 
SE  efforts;  include  the  due  date,  status,  and  program  stakeholders  by  organization  and 
position  (in  table  format)  (see  DoDI  5000.2  E3.  Enclosure  3,  E4.  Enclosure  4). 

•  The  plan  for  capturing  and  managing  these  requirements. 

•  How  the  program  will  identify,  analyze,  decompose,  and  allocate  the  SE-related  statutory 
and  regulatory  requirements. 

•  How  the  program  will  address  ESOH  considerations  in  the  SDD  phase  and  throughout 
the  system  life  cycle. 

2.3,  Specified  and  Derived  Requirements 

Describe  the  user’s  requirements  as  illustrated  by  the  program’s  specification  of 
requirements  and  derived  lower-level  requirements.  Include  a  specification  tree  to  illustrate 
the  decomposition  of  requirements  from  specified  to  derived. 

Consider  the  following: 

•  The  technical  plan  for  managing  and  integrating  all  specified  requirements  (e.g., 
performance,  materiel  availability)  according  to  the  applicable  system  or  performance 
specification. 

•  The  responsible  authority  for  derivation,  decomposition,  and  allocation  of  requirements. 

•  The  tools  (e.g.,  modeling  and  simulation  (M&S))  the  program  will  use  and  who  will  be 
responsible  for  ensuring  requirements  traceability. 

•  How  the  program  will  ensure  that  the  requirements  are  managed  across  contractual 
boundaries  down  to  the  subcontractor  level. 

•  How  the  program  requirements  (specified  and  derived)  will  be  managed,  tested,  traded, 
and  tracked. 

2.4,  Certification  Requirements 

Describe  the  program’s  plan  to  incorporate  the  applicable  program  certification 
requirements  into  the  system  design.  Eist  the  certification  requirements  levied  on  the  program 
at  each  level  of  development  (e.g.,  subsystem,  system,  integration,  interoperability,  joint,  and 
coalition),  including  the  applicable  source  for  the  certification  requirement  (i.e.,  statute, 
regulation,  or  instruction).  Describe  the  approach  for  understanding  the  potential  impact  of 
certification  requirements  on  the  system  design,  if  known  (see  DoDI  5000.2  E3.  Enclosure  3). 
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Consider  the  following: 

•  In  a  table:  the  list  of  eertifioations  (e.g.,  airworthiness,  SUBSAFE,  Clinger-Cohen  Act, 
interoperability,  spectrum  management)  that  are  applicable  to  the  program.  Include  the 
due  date,  status,  and  program  stakeholders  by  organization  and  position. 

•  Applicable  safety  boards  and  the  process  for  approval/concurrence. 

•  How  the  program  will  ensure  all  certification  requirements  are  integrated  with  the  overall 
set  of  requirements. 

•  How  the  certification  processes  will  integrate  with  the  program’s  design,  development, 
and  test  approach. 

•  How  the  program  will  manage  all  requirements  (statutory  and  regulatory,  specified  and 
derived,  and  certification)  and  integrate  them  with  the  KPPs. 

2,5,  Design  Considerations 

Describe  the  applicable  important  program  design  considerations  and  the  linkage  between 
system  operational  effectiveness  and  operational  suitability  to  satisfy  the  KPPs  (see  DAG 
4.4).  Characterize  any  special  design  considerations  that  must  be  integrated  into  the 
engineering  design  effort.  Describe  the  basis  for  these  and  other  key  design  considerations 
and  how  the  lead/chief  systems  engineer  will  be  involved.  Address  the  requirements  and 
planned  technical  approach  for  optimizing  system  operational  effectiveness  (SOE)  through 
the  balancing  of  system  performance,  system  availability,  interoperability,  and  total  system 
life-cycle  costs  (see  DAG  3.2.1.  4.1.3.  5. 1.3.5.  5.2.2.  5.4.2.I.  73,  SUP). 

Consider  the  following: 

•  How  the  program  will  identify,  address,  and  manage  the  full  range  of  applicable  design 
considerations  (see  DAG  4.4). 

•  How  the  architecture  products  (views,  diagrams,  descriptions,  models,  etc.)  are  related  to 
requirements  definition  as  well  as  the  functional  and  physical  architectures. 

•  How  the  program  will  link  engineering  activities  and  the  functional  and  design 
architecture  development  activities. 

•  How  the  program  will  update  and  address  system  interfaces  and  interoperability  needs 
from  SoS  and  external  system  dependencies  (see  SoS). 

•  How  the  program  will  incorporate  these  design  considerations  to  satisfy  the  KPPs  and 
system  requirements  (both  specified  and  derived). 

•  The  allocation  between  hardware  and  software  to  meet  plaimed  program  outcomes  and  to 
ensure  the  ability  to  accommodate  requirements  changes. 
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•  The  functional  organization/technical  authority  responsible  for  integrating  the  applicable 
design  considerations  into  the  overall  program. 

•  How  the  program  will  establish,  allocate,  and  manage  technical  performance  measures 
(e.g.,  materiel  availability,  system  assurance,  ESOH,  weight,  shape,  memory  capacity, 
and  throughput). 

•  How  the  program  will  negotiate  design  trades  to  support  threshold  and  objective 
requirements  to  balance  program  life-cycle  cost,  schedule,  performance,  and  sustainment 
while  also  addressing  security  and  risk  issues. 

•  The  stakeholders  responsible  for  making  trade-off  decisions,  and  at  what  level  in  the 
organization  the  decision  maker  resides. 

•  The  criteria  for  decision  making  and  trade-off  of  alternative  design  solutions  including 
descriptions  of  technical  objectives,  criteria,  and  weighting  factors. 

•  How  the  technical  approach  will  incorporate  proven  management  techniques  and 
capitalize  on  existing  programs  to  help  realize  SOE  objectives  (e.g..  Continuous  Process 
Improvement  (see  CPI),  Value  Engineering  (see  DAG  4.5.4),  Reduction  of  Total 
Ownership  Costs  (see  R-TOC)  etc.). 

3.  TECHNICAL  STAFFING  AND  ORGANIZATIONAL  PLANNING 

Describe  how  the  program  will  organize  and  staff  SE  activities  to  meet  the  requirements 
for  Milestone  B  and  the  SDD  phase  as  outlined  in  section  2  above.  Include  details  as 
recommended  in  paragraphs  3. 1-3.5. 

3,1,  Lead/Chief  Systems  Engineer  and  Functional  Leads 

Identify  the  lead/chief  systems  engineer’s  role  and  responsibility.  Identify  the  roles  and 
responsibilities  of  the  functional  leads  (functional  leads  outside  of  the  program  manager’s  (PM) 
chain  of  command  responsible  for  technical  processes,  products,  and  product  support). 

Consider  the  following; 

•  The  role  and  authority  of  the  lead/chief  systems  engineer  relative  to  SE  processes  and 
products  (technical  reviews,  technical  baselines,  etc.). 

•  The  functional  leads  required  to  address  the  integrated  set  of  technical  requirements 
(KPPs,  statutory,  regulatory,  specified,  certification,  and  design  considerations). 

•  The  organization  supporting  the  program  in  the  role  of  technical  authority. 

•  The  program’s  approach  to  integrating  technical  authority  on  appropriate  Integrated 
Product  Teams  (IPTs). 
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•  The  interaction  of  the  lead/chief  systems  engineer  and  the  functional  leads  to  address  the 
integrated  set  of  requirements. 

•  How  the  lead/chief  systems  engineer  and  functional  leads  will  present  to  the  PM  their 
recommendations  to  balance  cost,  schedule,  performance,  sustainment,  and  risk  in 
support  of  program  decisions. 

3.2,  IPX  Organization/Structure 

Describe  how  the  program  will  organize  and  structure  IPTs,  to  include  contractors  and  key 
suppliers  (when  applicable),  with  consideration  of  SE  to  meet  planned  program  outcomes. 
Include  IPT  charters  for  reference  (see  DAG  4.1.6). 

Consider  the  following: 

•  How  the  program  will  establish  a  product-aligned  IPT  structure.  Include  an 
organizational  chart  and  table  of  responsibilities  with  functional  representation. 

•  How  the  IPT  structure  will  align  with  the  program’s  products,  planned  outcomes,  and 
Work  Breakdown  Structure  (WBS). 

•  How  the  IPTs  will  involve  functional  representatives  and  other  stakeholders  (e.g.,  user, 
contractor,  technical,  sustainment,  financial,  security,  test).  (Identify  their  roles  and 
responsibilities  with  regard  to  the  requirements  and  design  considerations  addressed  in 
section  2.) 

3.3,  IPT  Staffing  /  Functional  Skills 

Describe  key  technical  staffing  requirements  for  the  program,  including  IPTs.  Identify  the 
required  number  of  key  technical  positions,  critical  skills,  and  experience  levels  necessary  to 
meet  the  technical  objectives. 

Consider  the  following: 

•  The  number  and  category  of  critical  skills  and  experience  required  to  fill  each  technical 
position  to  meet  program  objectives  (e.g.,  software,  design,  sustainment,  test  engineers). 

•  The  resources  available  to  the  program,  the  staffing  plan,  and  current  status  of  filling  the 
key  technical  positions  for  each  IPT. 

•  The  impact  of  unfilled  positions  (e.g.,  because  of  lack  of  funding,  lack  of  experienced 
people)  and  how  the  program  will  address  vacancies. 

•  In  a  diagram:  the  planned  staffing  levels  by  key  program  events  (e.g.,  milestones  and 
technical  reviews).  Include  a  chart  (e.g.,  a  sand  chart)  to  show  the  number  of  required 
full-time  equivalent  positions  (organic,  matrix  support,  and  contractor). 
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3.4,  IPX  Coordination 

Describe  how  the  program  will  integrate  SE  activities  within  and  among  IPTs  to  address 
the  full  spectrum  of  the  program. 

Consider  the  following; 

•  Specific  responsibilities  of  the  lead/chief  systems  engineer,  the  IPX  lead  engineers,  the 
SE  functional  leads,  and  the  Program  Executive  Office,  Systems  Center,  or  Systems 
Command  Chief  Engineer(s)  and  how  these  program  participants  will  communicate  and 
coordinate. 

•  How  the  program  will  manage,  integrate,  and  control  SE  products  across  the  IPTs. 

•  How  the  program  will  address  trade-off  analysis  to  adjudicate  disagreements  within  and 
across  IPTs. 

•  How  the  program  will  manage,  integrate,  and  control  the  IPX  structure  and  the  SE 
activities  and  products  (e.g.,  requirements;  technical  performance  measures  (TPMs); 
risks;  technical  baselines;  and  technical  budgets  such  as  weight,  power,  cost,  memory, 
and  throughput)  across  IPTs  to  support  overall  systems  design  and  integration  (hardware 
and  software). 

•  How  the  IPTs  will  involve  all  stakeholders  (e.g.,  users,  developers,  DT/OT  testers, 
functional  representatives,  software  specialists,  and  SMEs)  in  trade-off  and  design 
consideration  analysis  to  address  the  full  spectrum  of  technical  and  sustainment  program 
requirements. 

3.5,  Integration  with  Contractor(s)  and  External  Organizations 

Describe  how  the  program  will  facilitate  interaction  between  SE  WIPTs,  other 
government  organizations,  and  contractor(s)  (if  applicable)  on  technical  tasks,  activities,  and 
responsibilities  (e.g.,  requirements,  technical  baseline,  technical  reviews).  Describe  how  the 
SE  WIPE  will  document  the  technical  and  management  approach.  Describe  how  the  program 
will  coordinate  technical  requirements  and  specifications  with  functional  leads  external  to  the 
program  office  (e.g.,  SoS  efforts). 

Consider  the  following: 

•  How  the  SE  WIPE  will  contribute  to  and  document  the  technical  and  management 
approach. 

•  The  exit  criteria  for  the  SDD  phase  and  monitoring  its  accomplishment  for  all  increments 
of  capability. 

•  The  entry/exit  criteria  for  each  technical  review  and  audit. 
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•  The  execution  of  the  program  in  accordance  with  an  approved  SEP. 

•  The  lessons  learned  and  best  practices  throughout  DoD,  relevant  to  the  program’s 
technical  approach  and  status. 

•  How  the  program  will  organize  and  structure  technical  guidance  across  government  and 
contractor  SE  tasks,  activities,  and  responsibilities.  Describe  how  the  program  will 
coordinate  requirements  management,  technical  baseline  management  and  control,  and 
technical  review  execution  from  the  prime  contractor  through  all  subcontractors. 

•  The  applicability  of  SoS  technical  planning  in  the  interaction  with  higher  and  peer 
organizations  and  authorities,  external  to  the  program  office.  Describe  how  the  program 
will  integrate  requirements  and  coordinate  SoS-related  design  considerations  and  trades 
(see  DAG  AM;  SqS). 

4.  TECHNICAL  BASELINE  MANAGEMENT 

Describe  the  approach  for  managing  the  overall  technical  products  and  specifications  for 
Milestone  B  and  during  the  SDD  phase.  Include  details  as  recommended  in  paragraphs 
4.1-4.5. 

4.1,  Technical  Baseline  Management  Responsibility 

Describe  who  will  be  responsible  for  managing  the  technical  baseline  (functional, 
allocated,  and  product). 

Consider  the  following; 

•  The  role  and  responsibility  of  the  lead/chief  systems  engineer  for  managing  requirements 
allocated  to  product  IPTs. 

•  The  key  participants  and  the  plan  for  technical  baseline  management  (i.e.,  who  manages 
the  configuration)  of  the  system  across  IPTs  and  across  the  program  office,  contractor, 
and  subcontractors. 

•  The  role  and  responsibility  for  the  specification  and  test  planning  documents  to  support 
development  (see  DAG  4.2. 3. 6,  4.2. 3. 7,  4.2. 3. 8). 

4.2,  Defining,  Approving,  and  Maintaining  the  Technical  Baseline 

Describe  the  approach  to  define,  maintain,  and  approve  the  technical  baseline  (functional, 
allocated,  and  product). 

Consider  the  following; 

•  How  the  program  will  use  the  technical  baseline  as  a  technical  management  tool. 
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•  How  the  program  will  define,  approve,  and  maintain  the  teehnieal  baseline.  Include  a  list 
of  the  artifacts.  How  the  program  will  use  technical  reviews  to  establish  the  baseline. 

•  How  the  program  will  estimate  and  monitor  software  size  and  complexity  to  maintain 
accurate  and  current  cost  and  schedule  estimates. 

•  The  roles  and  responsibilities  between  the  government  and  the  contractor  for  defining, 
approving,  and  maintaining  the  technical  baseline. 

•  The  configuration  management  (CM)  process  the  program  will  use  to  manage  and  control 
changes,  waivers,  and  deviations  to  the  technical  baseline.  Include  a  diagram.  Describe 
the  lead/chief  systems  engineer’s  role  in  control  of  the  CM  process. 

•  The  program’s  approach  to  assess  the  baselines  relative  to  the  WBS  and  TPMs. 

•  How  the  program  will  review  system  documentation  as  well  as  technical  performance 
and  software  measures  to  continually  assess  progress  and  performance  against  the 
baseline. 

•  The  program  strategy  for  access  to,  or  delivery  of,  technical  data  and  computer  software 
and  other  information,  and  the  strategy  for  obtaining  sufficient  government  and 
contractor  data  rights  that  support  program  analysis  (M&S),  program  development  and 
production  objectives,  and  proposed  sustainment  strategy. 

4,3,  Requirements  Traceability  and  Verification  and  Validation 

Describe  the  allocation  and  verification  of  all  program  requirements  to  the  lowest-level 
configuration  items,  the  product  specification,  and  the  requirements  traceability  and 
verification  and  validation  (V&V)  process  across  the  entire  WBS. 

Consider  the  following: 

•  How  the  program  will  track  requirements  (KPPs,  statutory/regulatory,  specified/derived, 
and  certification  requirements,  along  with  verification,  architecture  and  design 
considerations,  etc.)  from  the  source  to  (and  throughout)  the  system  technical  baseline 
(e.g.,  specifications,  ICDs). 

•  The  approach  to  ensure  that  there  are  no  orphan  or  childless  requirements. 

•  The  tools  the  program  will  use  for  requirements  traceability  and  V&V  (to  include 
modeling  and  simulation  (M&S)),  and  who  will  be  responsible  for  these  activities  and 
tools  (see  DAG  4. 5. 7. 3) 

•  How  the  program  will  use  requirements  management  and  CM  to  support  establishing 
baselines  and  to  control  changes. 

•  The  planning  to  trace  and  map  requirements  from  initial  identification  to  V&V  efforts. 
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4.4,  Specification  Tree  and  WBS  Link 

Describe  and  illustrate  the  alignment  among  the  specification  tree;  the  functional, 
allocated,  and  product  baseline;  and  the  WBS.  Provide  a  copy  of  the  program  WBS  to  at  least 
Level  3. 

Consider  the  following; 

•  The  program  WBS  and  how  it  relates  to  the  end  item  configuration. 

•  The  planned  configuration  items  (CIs),  including  hardware  and  software  CIs. 

•  The  program’s  approach  to  documenting  the  technical  baseline  (system,  functional, 
subsystem,  and  design  specifications  and  standards)  and  alignment  between  the  WBS  and 
planned  technical  baseline  documents. 

•  The  program’s  planned  use  of  WBS  and  specifications  as  a  technical  management  tool 
across  the  SE  tasks. 

•  The  methods  the  program  will  use  to  show  traceability  of  top-level  requirements  (KPPs, 
certification,  statutory,  regulatory,  etc.)  and  key  safety  items  (e.g.,  critical  safety)  to  the 
JCIDS  requirements  documents  (ICD,  CDD,  or  CPD)  down  to  Cl  build-to  specifications 
and  V&V  plans. 

4.5,  Technical  Maturity 

Describe  how  the  program  will  use  the  technical  baseline  and  the  TRA  to  assess  technical 
maturity  and  associated  program  risk. 

Consider  the  following; 

•  In  a  table;  enabling  technologies  the  program  has  chosen;  Critical  Technology  Elements 
(CTEs);  and  currently  assessed  Technology  Readiness  Levels  (TRLs),  Manufacturing 
Readiness  Levels  (MRLs),  Engineering  and  Manufacturing  Readiness  Eevels  (EMRLs) 
and  desired  readiness  levels  at  completion  of  the  SDD  phase. 

•  The  program’s  plan  to  measure  technical  maturity  (as  opposed  to  only  TPM  tracking)  and 
to  continue  to  mature  technologies  in  accordance  with  the  statutory  equivalent  TRL 
requirements  for  all  critical  technology  elements  (CTEs)  in  support  of  Milestone  B 
entry/exit  criteria  (TRLs/MRLs). 

•  How  the  program  will  use  SE  products  (functional,  allocated,  and  product  baselines)  to 
establish  technical  maturity  to  assess  program  maturity  and  risk. 

•  The  program’s  plan  to  establish  technology  maturation  plans  (TMPs).  Include  the 
approach  for  applying  these  TMPs  across  the  program  WBS;  down  to  the  hardware  and 
software  Cl  level;  and  across  the  WBS  at  the  subsystem,  component,  and  device  levels. 
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•  How  the  evolving  acquisition  strategy,  sustainment  plan,  and  technical  planning  for 
future  phases  will  include  off-ramps  to  adapt  to  technology  maturation  delays  or  failure 
of  CTE  maturation. 


5.  TECHNICAL  REVIEW  PLANNING 

Describe  the  approach  to  establish  and  conduct  event-driven  technical  reviews  and  audits 
throughout  the  program  life  cycle  and  specifically  for  Milestone  B  and  during  the  SDD  phase 
(see  DAG  4.5.8).  Include  details  as  recommended  in  paragraphs  5. 1-5.5. 

5.1,  Event-Driven  Technical  Reviews 

Describe  the  event-driven  technical  reviews  to  be  conducted  at  a  system,  subsystem,  and 
configuration  item  level.  Identify  program-specific  entry  and  exit  criteria,  defined  and 
documented,  for  each  technical  review.  Describe  how  the  event-driven  technical  reviews  will 
be  conducted.  Describe  how  the  program  will  use  technical  reviews  to  establish  the  technical 
baselines  (see  DAG  4.2.3.3.  43,  43.2.4.  4.33.4.  43.3.9.  4.4.11.2.  4.5.3.  4.5.8). 

Consider  the  following: 

•  The  program’s  approach  to  executing  event-driven  technical  reviews  and  audits  to  ensure 
they  are  not  schedule  driven. 

•  The  planning  for  system-level  technical  reviews  (provide  a  schedule  of  all  SDD  technical 
reviews): 

-  The  number  of  technical  reviews  planned  and  to  what  WBS  level. 

-  The  technical  authority  (lead/chief  systems  engineer  and/or  functional  lead)  for 
entry/exit  criteria  for  each  review. 

-  The  technical  entrance/exit  criteria  for  each  review. 

-  The  readiness  for  conducting  each  review. 

•  The  timing  of  the  technical  reviews,  tied  to  the  achievement  of  entry  criteria  and  technical 
baseline  maturity. 

5.2,  Technical  Review  Management 

Describe  who  is  responsible  for  overall  management  of  the  technical  reviews. 

Consider  the  following: 

•  The  program’s  approach  for  oversight  and  conduct  of  all  technical  reviews. 

•  The  key  office  of  primary  responsibility(s)  and  stakeholders  involved. 
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•  How  the  program  will  determine  readiness  for  teehnieal  reviews  and  audits,  and  who  will 
be  responsible  for  making  the  deeision  to  authorize  and  elose  them  out. 

•  How  the  program  will  involve  funetional  leads  (see  DAG  4, 1.6). 

•  The  identifieation,  roles,  and  responsibilities  of  those  involved  in  eondueting  teehnieal 
reviews,  the  authority  that  approves  the  initiation  and  elosure  of  teehnieal  reviews,  and 
the  identification  and  disposition/closure  process  for  outstanding  actions  or  equivalent 
items  from  the  reviews. 

•  The  approach  to  ensuring  that  the  applicable  technical  products  (i.e.,  hardware,  software, 
or  process  specifications)  subject  to  each  review  and  audit  are  available  as  read-ahead 
material  to  the  appropriate  participants  (stakeholders  and  functional  leads). 

•  The  approach  for  integrating  the  outcomes  of  the  technical  reviews  into  the  program’s 
technical  plan. 

5.3,  Chairing  of  Technical  Reviews 

Describe  how  the  program  will  select  appropriate  chair(s)  for  the  technical  reviews.  (Best 
practice  is  to  use  independent  technical  authorities.)  Describe  the  role  of  the  lead/chief 
systems  engineer. 

Consider  the  following: 

•  The  approach  for  selecting  and  assigning  technical  review  and  audit  chairs. 

•  The  roles  of  the  PM,  lead/chief  systems  engineer,  and  the  technical  review  chair  and  how 
they  will  collaborate  on  technical  reviews,  especially  the  determination  of  readiness  for 
the  review  or  audit,  and  on  reporting  of  results. 

•  How  the  program  will  ensure  that  reviews  are  conducted  to  according  to  established  DoD 
policy  and  engineering  preferred  practice. 

5.4,  Stakeholder  Participation  in  Technical  Reviews 

Describe  who  the  stakeholders  are  and  how  they  will  be  involved  in  each  technical  review 
to  cover  all  technical  requirements,  including  KPPs;  statutory,  regulatory,  certification,  and 
V&V  requirements;  and  all  design  considerations  (see  DAG  4.1.2). 

Consider  the  following: 

•  How  the  program  will  involve  appropriate  stakeholders  (i.e.,  users,  testers,  ESOH, 
certifiers,  design  and  sustainment  engineers)  and  representative  offices  from  design  areas 
at  key  decision  points  (e.g.,  airworthiness  certifiers  at  technical  reviews). 

•  The  program’s  plan  to  involve  stakeholders  (e.g.,  users,  testers,  safety,  certifiers,  design 
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and  sustainment  engineers)  by  organization  in  reviews  and  audits. 

•  How  the  program  office,  contractor  and  subcontractors  (when  applicable),  and  relevant 
industry  representatives  will  participate  in  reviews  and  audits. 

•  The  membership  composition,  including  the  method  for  nominating  and  approving  the 
chairperson  and  membership  of  a  technical  review  board,  if  required. 

•  How  the  program  office  will  reconcile  resource  constraints  with  technical  staffing  needs 
for  the  reviews  and  audits. 

•  The  program’s  approach  to  involve  the  test  and  sustainment  communities  in  the  SE 
process  to  assess  risk  and  to  participate  in  technical  reviews  to  mature  the  technical 
baseline  (see  DoD  5000.2  E5.  Enclosure  5). 

5,5,  Peer  Participation  at  Technical  Reviews 

Describe  how  the  program  will  facilitate  peer  review  participation  for  each  of  the 
technical  reviews  (see  DoD  policy). 

Consider  the  following: 

•  The  program’s  approach  to  addressing  peer  review  in  accordance  with  DoD  policy  and 
how  peers  will  participate  in  technical  reviews. 

•  The  program’s  method  to  identify  the  subject  matter  areas  in  which  peer  insight  is  most 
relevant,  and  how  the  program  will  access  these  SMEs. 

•  The  planned  participation  of  senior  leadership  or  SMEs  in  functional  areas  at  major 
reviews  or  at  other  key  decision  points. 


6.  INTEGRATION  WITH  OVERALL  PROGRAM  MANAGEMENT 

Describe  the  relationship  between  SE  and  key  program  management  processes  and 
strategies.  Describe  how  program  staff  working  in  SE  and  other  areas  will  exchange  feedback 
and  provide  information  to  support  reporting  and  milestone  requirements  for  Milestone  B  and 
during  the  SDD  phase  (see  DoDI  5000.2,  E3.  Enclosure  3).  Include  details  as  recommended 
in  paragraphs  6. 1-6.5. 

6,1,  Linkage  to  Other  Program  Management  Plans 

Describe  how  the  program  will  integrate  the  technical  approach  with  other  related 
program  management  planning  and  control  efforts  (i.e.,  the  AS,  WBS,  RMP,  PESHE,  IMP 
and  IMS,  PPP,  and  Earned  Value  Management  (EVM),  etc.).  Characterize  the  approach  to 
determine  progress-to-date  assessments  to  support  cost  reporting  and  event-driven  scheduling 
(see  DAG  11.3). 
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Consider  the  following: 

•  The  program’s  approach  to  using  other  management  reviews  and  activities  (Program 
Management  Reviews  (PMRs),  Technical  Interchange  Meetings  (TIMs),  Independent 
Reviews,  etc.)  to  manage  the  overall  technical  program. 

•  How  the  program  will  ensure  that  the  technical  planning  and  the  IMP/IMS  include  any 
required  Government  Provided  Property  (e.g.,  test  ranges,  integration  laboratories,  and 
special  equipment)  to  support  System  Development  and  Demonstration.  Include  link  to 
the  program’s  IMP/IMS. 

•  The  use  of  IMS  and  the  WBS  as  the  basis  for  the  Integrated  Baseline  Review  (IBR),  cost 
accounts,  and  EVM  implementation  (see  DAG  1 1.3. 1.3). 

•  The  use  of  SE  analysis  in  resource  estimation  (see  DoDI  5000.2  E6.  Enclosure  6). 

•  The  program’s  approach  for  using  metrics  to  monitor  prime  and  subcontractor 
performance  for  indicators  of  impacts  to  cost,  schedule,  and  performance,  (i.e.,  software 
development  metrics;  technical  performance  measures  (TPMs);  Critical  Technical 
Parameters  (CTPs);  measures  of  effectiveness  (MOEs);  measures  of  suitability  (MOSs); 
measures  of  performance  (MOPs);  and  Sustainment  KPP/KSAs  (i.e..  Materiel 
Availability,  Materiel  Reliability,  Ownership  Cost,  and  Mean  Down  Time)).  In  a  table: 
the  metrics,  provider,  and  reporting  frequency. 

•  The  use  of  SE  (analysis,  technical  data,  and  decisions)  to  support  other  program  activities 
and  key  program  documents  requiring  MDA  approval  (see  DoDI  5000.2 

E3.  Enclosure  3). 

•  The  process  for  integrating  program  protection  with  SE  efforts. 

6,2,  Program  Manager’s  Approach  to  Using  Technical  Reviews 

Describe  how  the  program  manager  will  use  technical  review  results  to  formally  advance 
the  program  through  its  plaimed  evolution  (e.g.,  establishing  a  baseline  at  CDR). 

Consider  the  following: 

•  How  the  PM  will  use  the  technical  review  results  as  a  technical  input  to  program  decision 
making. 

•  The  role  of  the  PM  in  preparing,  executing,  and  resolving  issues  from  technical  reviews. 

•  The  method  for  the  continual  and  accurate  identification  and  management  of  the  critical 
path  tasks. 
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6.3,  Risk  Management  Integration 

Describe  the  program’s  risk  management  approach  along  with  any  SoS  risk  consideration. 
Describe  how  risk  management  is  integrated  with  SE  planning  efforts  (e.g.,  describe  how  the 
program  and  SoS  technical  reviews  provide  a  technical  risk  input  to  the  risk  management 
process).  Describe  the  linkages  between  the  technical  risk  assessment,  risk  mitigation  efforts, 
and  the  overall  risk  management  process  (see  DAG  4.2. 3. 5,  1 1.4;  RMG). 

Consider  the  following; 

•  How  the  RMP  (including  any  related  SoS  RMP)  is  integrated  with  the  technical  approach 
and  addresses  life-cycle  sustainment  considerations  (see  RMG  Ch.  8;  DAG  11.4). 

•  The  linkage  between  the  technical  reviews  and  the  program’s  risk  assessment  process 
(i.e.,  risks  of  successful  completion  of  the  next  technical  review)  (see  RMG;  DAG  4.5.8). 

•  The  risk  management  tool  the  program  office  will  use  and  the  tool’s  compatibility  with 
the  prime  contractor’s  and  subcontractor’s  tools. 

•  How  often  risks  will  be  reviewed,  by  whom,  and  how  risks  will  be  communicated. 

•  How  the  program  will  use  metrics  in  the  risk  assessment  process. 

•  The  manager  of  the  risk  program  and  how  IPTs  will  apply  risk  management. 

•  How  the  program  will  address  risks  and  issues. 

•  How  the  program  will  address  the  system  ESOH  objectives  and  risks  as  outlined  in  MTT.- 
STD-882D. 

•  How  risks  and  SE  will  be  included  in  the  IMP/IMS  and  linked  in  the  program  life-cycle 
planning. 

•  How  software  and  SE  risks  will  be  linked  in  the  program  planning. 

•  How  to  minimize  risks  during  the  transition  from  development  to  production  (see  DpD 
4245. 7-M). 

•  A  summary  of  key  SE  technical  risks,  including  interfaces  and  interdependencies  with 
ratings  and  mitigation  plans. 

6.4,  Test  and  Evaluation 

Describe  the  integration  of  test  and  evaluation  (T&E)  planning  within  the  SE  approach. 

Consider  the  following; 

•  How  the  measures  of  effectiveness  and  suitability,  KPPs,  and  critical  technical  measures 
are  stated  as  quantifiable  parameters. 

•  How  verification  and  validation  (V&V)  plans  will  be  integrated  in  the  SE  approach, 
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particularly  how  test  objectives  in  the  TEMP  will  be  traceable  to  performance 
requirements  in  the  system  specifications. 

•  The  methods  the  program  will  use  for  verification  (inspection,  analysis  (M&S), 
demonstration,  and  test)  to  ensure  requirements  will  be  addressed  in  T&E  at  the  system 
and  subsystem  level  (see  DAG  4.5.7.3). 

•  The  use  of  M&S  and  prognostics  in  support  of  T&E  life-cycle  sustainment  objectives. 

•  The  integration  of  the  TEMP  within  the  overall  technical  planning. 

6.5,  Sustainment  Integration 

Describe  the  dependency  and  interplay  between  system  performance,  producibility, 
materiel  availability,  materiel  reliability,  ownership  cost  and  mean  down  time  throughout  the 
system  life  cycle  (see  SLIP  1.3). 

Consider  the  following; 

•  The  implementation  of  SE  in  support  of  a  Total  Systems  Approach  to  achieve  the 
mandatory  sustainment  KPP/KSAs  (i.e.,  materiel  availability,  materiel  reliability, 
ownership  cost,  and  mean  down  time),  and  the  life-cycle  sustainment  enablers  (e.g., 
corrosion,  RCM,  SIM)  (see  SUP  1.3,  3.4;  DAG  2.3.12.  4.1.3.  5.2.2:  DoDD  5000.1). 

•  The  use  of  M&S  and  prognostics  in  support  of  T&E  life-cycle  sustainment  objectives. 

•  The  integration  of  the  Eife-Cycle  Sustainment  Plan  within  the  overall  technical  planning. 

•  How  the  design  addresses  sustainment,  obsolescence,  technology  refreshment,  and 
disposal. 

6.6,  Contracting  Considerations 

Describe  SE  considerations  for  the  SDD  phase  to  incorporate  strong  SE  (see  DAG  4.3; 
Integrating  Systems  Engineering  into  DoD  Acquisition  Contracts). 

Consider  the  following; 

•  The  linkage  between  the  MDA-approved  SEP  and  the  contractor’s  technical  plan  System 
Engineering  Management  Plan  (SEMP)  to  establish  a  fully  integrated  technical  approach. 

•  How  SE  is  factored  into  the  REP  and  contract,  including  subcontractors,  as  an  integral 
part  of  the  development  effort. 

•  The  technical  basis  for  performance-based  payments  and  award  fees. 

•  How  the  contractors’  software  plans  and  related  processes  (e.g..  Software  Development 
Plan  (SDP))  will  be  assessed  and  integrated  with  SE  plans  and  processes. 
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How  the  program  will  incorporate  SE  and  technical  guidelines  into  SDD  contract 
planning  to  serve  as  incentives  for  the  contractor  performance  to  produce  the  most 
effective  and  effective  program  outcomes  (e.g.,  in  the  areas  of  materiel  availability  and 
materiel  reliability,  ownership  costs,  and  mean  down  time). 

How  the  contract  will  encourage  event-driven  reviews  and  technical  baseline 
management  across  the  program,  including  between  contractors  and  subcontractors. 

How  contractors’  capabilities  to  conduct  life-cycle  systems  and  software  engineering 
activities  will  be  assessed  for  security-related  practices,  foreign  ownership  control  and 
influence,  and  protection  of  Critical  Program  Information  (CPI). 
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1.  INTRODUCTION 

Discuss  the  purpose  of  the  SEP,  who  will  use  it,  and  how  it  will  be  used  to  define  the 
blueprint  for  the  conduct,  management,  and  eontrol  of  the  teehnical  aspects  of  the  program 
from  produetion  to  disposal.  Discuss  the  eommitment  to  update  the  doeument  throughout  the 
Produetion  and  Development  (PD)  /  Operations  and  Support  (O&S)  phases  to  make  it  a  living 
doeument  and  the  plan  to  link  the  contraetor’s  Systems  Engineering  Management  Plan 
(SEMP)  to  the  SEP. 

1.1,  Program  Description  and  Applicable  Documents 

Provide  a  top-level  mission  deseription  that  summarizes  the  user’s  requirements  as 
doeumented  in  the  Capability  Produetion  Document  (CPD).  Convey  the  overall  key  elements 
of  the  program,  ineluding  any  system  of  systems  (SoS)  relationships,  by  using  appropriate 
DoD  Arehitecture  Eramework  views  (e.g..  Operational  View-1)  and  supporting  narrative. 
Include  a  system  deseription  and  a  notional  diagram  of  the  system. 

Diseuss  the  relationship  between  the  SEP  and  the  doeuments  developed  or  updated  during 
the  PD  and  O&S  phases.  Eor  example,  inelude  the  funding  profde;  Aequisition  Strategy; 
System  Threat  Assessment  (STA);  Programmatic  Environmental,  Safety  and  Occupational 
Health  (ESOH)  Evaluation  (PESHE);  Information  Support  Plan  (ISP);  Capability 
Development  Doeument  (CDD);  Program  Protection  Plan  (PPP);  Risk  Management  Plan 
(RMP);  Integrated  Master  Plan  (IMP)  and  Integrated  Master  Sehedule  (IMS);  the  Test  and 
Evaluation  Master  Plan  (TEMP).  Cross-referenee  overarehing  or  subordinate  SoS  program- 
related  SEPs.  Eist  the  points  of  contact  for  all  the  doeuments. 

1.2,  Current  Program  Status 

Summarize  the  overall  Aequisition  Strategy  and  how  it  is  event  driven.  Deseribe  how  the 
program  is  prepared  to  transition  into  PD  and  O&S.  Deseribe  the  aeeomplishment  of  the 
required  SDD  exit  eriteria  and  list  any  remaining  eritical  aetions.  Highlight  the  outeomes  of 
major  activities  the  program  has  eondueted  to  date,  such  as  technical  reviews,  test  phases, 
independent  reviews,  risk  reduetion  activities,  and  trade  studies. 

Provide  a  detailed  program  sehedule  that  shows  major  milestones,  SE  technical  reviews, 
and  key  program  events  (e.g.,  developmental,  operational,  and  live  fire  test  phases;  deliveries; 
certifications;  contract  awards;  training;  site  activation). 

1.3,  Approach  for  SEP  Updates 

Describe  the  approach  for  updating  the  SEP.  Deseribe  the  primary  sources  and  event 
triggers  for  SEP  updates  and  include  a  log  traeing  changes  to  the  original  doeument.  Inelude 
a  brief  explanation  of  what  drove  the  change  (e.g.,  new  direetion  or  requirements,  funding 
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issues,  technical  issues,  or  normal  program  maturation,  etc.).  List  any  previous  SEP 
submittals  by  date. 

2.  PROGRAM  REQUIREMENTS 

Provide  a  brief  description  of  the  overall  mission  needs  and  operational  and  sustainment 
concept  as  a  basis  for  Milestone  C  and  during  the  PD  and  O&S  phases  of  the  program. 

Include  details  as  recommended  in  paragraphs  2. 1-2.5). 

2.1,  Technical  Oversight  Approach 

Describe  the  technical  oversight  approach  to  be  applied  during  the  PD  and  O&S  phases 
(i.e.,  systems  supported  using  Continuous  Process  Improvement  (CPI)  principles  and  how 
well  the  technical  approach,  data  collection,  and  analysis  methodology  supports  the 
optimization  of  planned  life-cycle  support  and  materiel  availability  requirements). 

Consider  the  following; 

•  The  method  to  ensure  technical  oversight  in  PD  and  O&S. 

•  How  the  program  will  monitor  all  relevant  PD  and  O&S  data. 

•  How  the  program  will  develop,  define,  model,  manage,  test,  trade,  and  track  capabilities. 
Key  Performance  Parameters  (KPPs)  (i.e.,  materiel  availability,  force  protection  and  net- 
ready  capability),  and  other  PD  and  O&S  related  requirements. 

•  How  the  program  will  satisfy  the  statutory,  regulatory,  and  certification  requirements  that 
are  applicable  to  SE  efforts;  include  the  due  date,  status,  and  program  stakeholders  by 
organization  and  position  (in  table  format)  (see  DoDI  5000.2  E3.  Enclosure  3,  E4. 
Enclosure  4). 

•  The  responsibilities  of  all  program  stakeholders  involved  in  technical  oversight  of 
production,  production  tooling  and  processes,  deployment,  operations,  and  support  across 
the  supply  chain. 

•  How  the  program  will  address  system  design  considerations  (e.g.,  ESOH)  throughout  the 
system  life  cycle. 

2.2,  Comparison  of  Data  to  Planning  Assumptions 

Describe  how  the  technical  approach  reflects  how  the  program  will  track  and  analyze  PD  and 
O&S  data  and  compare  it  against  planning  assumptions  made  during  design  and  development. 

Consider  the  following; 

•  The  PD  and  O&S  data  (e.g.,  achievement  versus  producibility  goals,  production  learning 
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curve,  materiel  availability,  materiel  reliability,  ownership  cost,  and  mean  down  time)  to 
be  tracked  and  assessed  in  support  of  the  SE  activities. 

•  The  plan  for  analyzing  (modeling  and  simulation  (M&S))  and  employing  data  to  manage 
the  achievement  of  planned  outcomes. 

•  How  the  technical  approach  will  capitalize  upon  the  results/analysis  of  PD  and 
O&S  data. 

•  The  program  stakeholders,  by  organization  and  position,  for  the  PD  and  O&S  data 
requirements  collection  and  analysis. 

2.3,  Use  of  Data  to  Continuously  Monitor  the  System 

Describe  how  the  program  will  collect,  triage,  model,  analyze,  and  assess  production  and 
O&S  data  to  continuously  monitor  system  hazards  and  risks;  integrity  of  key  safety  items 
(e.g.,  critical  safety  items);  key  manufacturing  characteristics;  materiel  availability;  materiel 
reliability;  ownership  cost;  mean  down  time;  and  maintenance  of  applicable  system 
certifications  (i.e.,  airworthiness,  SUBSAFE,  etc). 

Consider  the  following: 

•  The  technical  plan  for  managing,  integrating,  and  controlling  PD  and  O&S  data  (e.g., 
conduct  of  trend  analysis  of  planned  versus  actual  data,  unit  recurring  cost,  etc.)  in  order 
to  assess  and  increase  productivity  and  reduce  life-cycle  cost. 

•  The  responsible  authority  for  derivation,  decomposition,  and  allocation  of  PD  and  O&S 
data  requirements. 

•  The  tools  (e.g.,  M&S)  used  and  the  organizations  responsible  for  ensuring  PD  and  O&S 
data  requirements  traceability,  integrity,  and  management  (see  DAG  4. 5. 7.4,  4. 5. 7. 5). 

•  How  the  program  will  ensure  that  PD  and  O&S  data  are  collected  and  managed  across 
government  organizational  and  contractual  boundaries  (subsystem  contractors)  and 
sustainment  functions  (supply,  maintenance,  distribution,  and  in-service  engineering). 

•  How  the  program  will  manage,  test,  trade,  and  track  program  requirements  (specified  and 
derived  lower-level  requirements). 

2.4,  Production  and  Design  Driven  Operations  &  Support  Costs 

Describe  the  program’s  approach  to  tracking  and  controlling  PD-driven  and  design-driven 
O&S  costs  (e.g.,  production  costs,  reliability  performance-to-plan,  corrosion-related  costs, 
maintenance  and  repair  costs)  and  total  ownership  costs  (TOC)  (see  DoDI  5000.2  E3. 
Enclosure  3). 

Consider  the  following: 
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•  How  the  program  will  identify,  track,  and  analyze  PD-driven  and  design-driven  O&S 
costs,  integrate  the  costs  into  the  overall  program  cost,  establish  schedule  and 
performance  baselines,  and  ensure  that  funding  and  sustainment  are  included  in  the 
affordability  assessment. 

•  The  responsible  stakeholder(s)  for  collaborating  on  the  PD  and  system-driven 
O&S  costs. 

•  How  the  O&S  costs  (i.e.,  driven  by  materiel  availability,  materiel  reliability,  ownership 
cost,  and  mean  down  time)  relate  to  the  budgeted  and  resourced  O&S  investment. 

•  How  the  program  will  identify,  assess,  and  minimize  TOC  drivers. 

•  How  the  program  will  provide  system-specific  data  required  to  complete  National 
Environmental  Policy/EO  12114  analysis  (when  applicable)  and  documents  to  support 
operational  test  and  evaluation  and  basing. 

•  How  the  technical  approach  will  incorporate  proven  management  techniques  and 
capitalize  on  existing  programs  to  help  realize  System  Operational  Effectiveness  (SOE) 
objectives  (e.g..  Continuous  Process  Improvement  (see  CPI),  Value  Engineering  (see 
DAG  4.5.4),  Reduction  of  Total  Ownership  Costs  (see  R-TOC),  etc.). 

2,5,  Configuration  Changes 

Describe  how  the  program  will  determine,  manage,  and  control  configuration  changes 
during  the  PD  and  O&S  phases  (i.e.,  as-designed,  as-built,  as-maintained  configurations)  (see 
DAG  4.1.3,  5. 1.3.5,  5.2.2,  5.2.3,  5.4.2. 1,  73;  SUP). 

Consider  the  following: 

•  How  the  program  will  update  and  address  system  interfaces  and  interoperability  changes 
from  SoS  and  external  system  dependencies  (see  DAG  7.3). 

•  How  the  program  will  translate  Technical  Order  changes  against  the  in-service  system 
into  production  and  follow-on  system  increments  under  consideration  or  development. 

•  How  the  program  will  consider  and  implement  operational  and  sustainment-related 
changes  (results  from  O&S),  deferred  capabilities,  and  new  requirements. 

•  How  the  program  will  consider  and  implement  lessons  learned  from  Eow-Rate  Initial 
Production  (TRIP)  to  improve  efficiency,  quality,  and  capacity  and  to  improve 
production  and  sustainment. 

•  How  the  program  will  evaluate  O&S  data  to  determine  potential  configuration  changes 
that  would  improve  materiel  availability  and  reduce  TOC. 

•  How  the  program  will  address  important  design  considerations  in  proposed  configuration 
changes  (e.g.,  producibility  and  sustainment)  (see  DAG  4.4). 
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•  How  the  architecture  products  (views,  diagrams,  descriptions,  models,  etc.)  are  related  to 
requirements  definition  as  well  as  the  functional  and  physical  architecture. 

•  How  the  program  will  link  engineering  activities  with  functional  and  design  architecture 
development  activities. 

•  The  functional  organization  /  designated  technical  authority  responsible  for  overseeing 
trusted  sources  and  approving  configuration  changes  for  key  safety  items  (e.g.,  critical 
safety  items)  and  other  system  components. 

•  How  the  program  will  establish,  allocate,  and  manage  technical  performance  measures  to 
support  configuration  changes  (e.g.,  materiel  availability,  systems  assurance,  ESOH, 
shape,  weight,  memory  capacity,  and  throughput). 


3.  TECHNICAL  STAFFING  AND  ORGANIZATIONAL  PLANNING 

Describe  how  the  program  will  organize  and  staff  SE  activities  to  meet  the  requirements 
for  Milestone  C  and  during  the  PD  and  O&S  phases.  Include  details  as  recommended  in 
paragraphs  3 . 1-3 .5 . 

3,1,  Lead/Chief  Systems  Engineer  and  Functional  Leads 

Identify  the  lead/chief  systems  engineer’s  role  and  responsibility.  Identify  the  roles  and 
responsibilities  of  the  functional  leads  (functional  leads  outside  of  the  program  manager’s 
(PM)  chain  of  command  responsible  for  technical  processes,  products,  and  product  support). 
Address  the  full  spectrum  of  technical  surveillance  needs  and  how  they  will  be  implemented 
on  the  program  (see  DAG  4.1.6). 

Consider  the  following; 

•  The  role  and  authority  of  the  lead/chief  systems  engineer  relative  to  the  adequacy  and 
recommendation  for  Milestone  C  entry/exit  criteria,  and  SE  processes  and  products  (e.g.. 
Operational  Test  Readiness  Review  (OTRR),  Technology  Readiness  Assessment, 
Production  Readiness  Review  (PRR)  and  In-Service  Review  (ISR),  Physical 
Configuration  Audit  (PCA)  and  Eunctional  Configuration  Audit  (FCA),  and  technical 
baselines). 

•  The  functional  leads  required  to  address  the  integrated  set  of  technical  requirements 
(KPPs,  statutory,  regulatory,  specified,  certification,  and  design  considerations). 

•  The  organization  supporting  the  program  in  the  role  of  technical  authority  (including  in- 
service  engineering  authority). 

•  The  program’s  approach  to  integrating  technical  authority  or  their  representative  on 
appropriate  Integrated  Product  Teams  (IPTs). 
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•  The  interaction  of  the  lead/chief  systems  engineer  and  the  functional  leads  to  address  the 
technical  surveillance  needs. 

•  How  the  lead/chief  systems  engineer  and  the  functional  leads  will  present  to  the  PM  their 
recommendations  to  balance  cost,  schedule,  performance,  sustainment,  and  risk  in 
support  of  program  decisions. 

3.2,  IPX  Organization/Structure 

Describe  how  the  program  will  organize  IPTs  with  consideration  of  SE  to  meet  planned 
program  outcomes.  Provide  IPX  charters  for  reference  (see  DAG  4.1.6). 

Consider  the  following; 

•  How  the  program  will  establish  a  product-aligned  IPX  structure  (include  an 
organizational  chart  and  a  table  of  responsibilities  showing  functional  representation). 

•  How  the  IPX  structure  for  the  engineering  support  team  aligns  with  the  program’s 
products,  planned  outcomes,  and  Work  Breakdown  Structure  (WBS). 

•  How  the  engineering  support  team’s  IPX  will  accommodate  functional  representatives 
and  other  stakeholders  (user,  contractor,  technical,  sustainment,  cost,  budget,  production, 
security,  and  test)  and  identify  their  roles  and  responsibilities  with  regard  to  the 
requirements  and  design  considerations  addressed  in  section  2. 

3.3,  IPX  Staffing  /  Functional  Skills 

Describe  the  key  technical  staffing  requirements  for  the  program,  including  each  IPX; 
identify  the  required  number  of  key  technical  positions,  critical  skills,  and  experience  levels 
necessary  to  meet  the  technical  objectives. 

Consider  the  following; 

•  The  number  and  category  of  SMEs;  critical  skills  and  experience  required  to  fill  each  IPX 
to  meet  the  program’s  PD  and  O&S  objectives  (e.g.,  industrial,  software,  design, 
sustainment,  and  test  engineers,  and  supply  chain  technicians). 

•  The  resources  available  to  the  program,  the  staffing  plan,  and  current  status  of  filling  the 
key  technical  positions  for  each  IPX  (including  production  and  sustainment). 

•  The  impact  of  unfilled  positions  (e.g.,  because  of  lack  of  funding,  lack  of  experienced 
people)  and  how  the  program  will  address  vacancies. 

•  Provide  a  diagram  that  shows  the  planned  staffing  levels  by  key  program  events  (e.g., 
milestones  and  technical  reviews).  Include  a  sand  chart  to  show  the  number  of  full-time 
equivalent  positions  (organic,  matrix  support,  and  contractor). 
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3.4,  IPX  Coordination 

Describe  how  the  program  will  integrate  and  coordinate  SE  activities  within  and 
across  IPTs. 

Consider  the  following; 

•  Specific  responsibilities  of  the  lead/chief  systems  engineer,  the  IPX  lead  engineers,  the 
SE  functional  leads,  and  the  Program  Executive  Office,  Systems  Center,  or  Systems 
Command  Chief  Engineer(s)  and  how  these  program  participants  will  communicate  and 
coordinate. 

•  How  the  program  will  manage,  integrate,  and  control  SE  products  and  processes  across 
the  IPTs. 

•  How  the  program  team  will  present  trade-off  decisions  to  adjudicate  disagreements 
within  and  across  IPTs. 

•  How  the  program  will  manage,  integrate,  and  control  the  IPX  structure  and  the  SE 
activities  and  products  (estimates,  assessments,  risks,  requirements,  and  technical 
baselines)  to  support  production  and  sustainment. 

•  How  the  IPTs  will  involve  all  stakeholders  (e.g.,  users,  logisticians,  production  leads, 
developers,  DT/OT  testers,  functional  leads,  and  SMEs)  in  trade-off  consideration 
analysis. 

3.5,  Integration  with  Contractor(s)  and  External  Organizations 

Describe  how  the  program  will  facilitate  interaction  between  SE  WIPTs,  other 
government  organizations,  and  contractor(s)  (if  applicable)  on  technical  tasks,  activities,  and 
responsibilities  (e.g.,  requirements,  technical  baseline,  technical  reviews)  down  to  and 
including  subcontractors.  Describe  how  the  SE  WIPE  will  document  the  technical  and 
management  approach  in  the  SEP.  Describe  how  the  program  will  coordinate  technical 
requirements  and  specifications  with  functional  leads  external  to  the  program  office  (e.g.,  SoS 
efforts)  (see  SoS). 

Consider  the  following: 

•  How  the  SE  WIPE  will  contribute  to  and  document  the  technical  and  management 
approach. 

•  The  entry  and  exit  criteria  for  the  Pull  Rate  Production/Deployment  Decision  and 
monitoring  its  accomplishment  for  all  increments  of  capability. 

•  The  entry  and  exit  criteria  for  each  technical  review  and  audit. 

•  The  execution  of  the  program  in  accordance  with  an  approved  SEP. 
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•  The  lessons  learned  and  best  praetices  throughout  DoD,  relevant  to  the  program’s 
technical  approach  and  status. 

•  The  overall  organization  and  structure  to  provide  technical  guidance  across  government 
and  contractor  SE  tasks,  activities,  and  responsibilities.  Describe  how  the  program  will 
coordinate  requirements  management,  technical  baseline  management  and  control, 
technical  review  execution,  and  sustainment  from  the  prime  contractor  to  the 
subcontractors. 

•  As  applicable,  the  SoS  technical  planning  in  cooperation  with  higher  and  peer 
organizations  and  authorities  external  to  the  program  office  (see  DAG  4.2.6;  SoS). 


4.  TECHNICAL  BASELINE  MANAGEMENT 

Describe  the  approach  for  managing  the  overall  technical  products  and  specifications  for 
Milestone  C  and  during  the  PD  and  O&S  phases.  Include  details  as  recommended  in 
paragraphs  4. 1^.5. 

4.1,  Technical  Baseline  Management  Responsibility 

Describe  who  is  responsible  for  managing  the  technical  baselines,  particularly  the  product 
baseline  and  the  configuration  management  (CM)  process. 

Consider  the  following; 

•  The  role  and  responsibility  of  the  lead/chief  systems  engineer  for  managing  requirements 
allocated  to  product  IPTs. 

•  The  key  participants  and  the  plan  for  technical  baseline  management  (i.e.,  who  manages 
the  configuration)  of  the  system  across  IPTs  and  across  the  program  office,  contractor, 
and  subcontractors. 

•  The  role  and  responsibility  for  specification  and  test  planning  documents  that  support 
production  and  sustainment  (see  DAG  4.2. 3. 6,  4.2. 3. 7,  and  4.2. 3. 8). 

4.2,  Technical  Baseline  Control 

Describe  how  the  program  will  manage  and  control  the  system’s  technical  baseline. 
Consider  the  following: 

•  The  process  for  developing  technical/design  modifications. 

•  The  program’s  approach  to  using  the  technical  baseline  as  a  technical  management  tool. 

•  How  the  program  will  define,  approve,  and  maintain  the  technical  baseline.  Include  a  list 
of  artifacts. 
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•  The  use  of  the  produet  baseline  to  manage  and  eontrol  system  development  in  support  of 
produetion  and  sustainment  objeetives. 

•  How  the  program  will  update  and  monitor  as-delivered  software  size  and  eomplexity  to 
form  the  basis  of  eost  and  sehedule  estimates  for  follow-on  releases. 

•  The  roles  and  responsibilities  between  the  government  and  the  eontraetor  for  defining, 
approving,  and  maintaining  the  technieal  baseline. 

•  How  the  program  will  use  technical  reviews  to  manage  the  system’s  technical  baseline 
and  to  continually  assess  new  or  emerging  technology  to  achieve  new  program 
objectives. 

•  The  CM  process  used  to  manage  and  control  the  baselines.  Include  a  diagram  of  the 
process.  Describe  the  lead/chief  engineer’s  role  in  the  CM  process  (see  CM). 

•  The  program  strategy  for  access  to  or  delivery  of  technical  data,  computer  software,  and 
other  information,  and  for  obtaining  sufficient  government  and  contractor  data  rights  that 
support  program  analysis  (M&S),  program  development  and  production  objectives,  and 
proposed  sustainment  strategy. 

4,3,  Requirements  Traceability  and  Verification  and  Validation 

Describe  how  the  technical  baseline  will  account  for  requirements  and  certification 
traceability  and  requirements  verification  and  validation  (V&V)  for  any  changes  to  the 
baseline,  including  key  safety  items  (e.g.,  critical  safety  items). 

Consider  the  following; 

•  How  the  program  will  track  requirements  changes  to  the  baseline  (KPPs,  statutory/ 
regulatory,  specified/derived,  and  certification  requirements,  along  with  verification, 
architecture,  design  considerations,  production,  etc.)  to/from  the  source  to  (and 
throughout)  the  system  technical  baseline  and  specification  tree. 

•  The  approach  to  ensure  that  there  are  no  orphan  or  childless  requirements  changes  to  the 
baseline. 

•  The  tools  used  for  requirements  traceability  and  V&V  (i.e.,  M&S),  and  by  whom  (see 
DAG  4.5.7.4.  4.5.7.5). 

•  Requirements  management  traceability  linked  to  CM  and  to  changes  to  the  technical 
baseline. 

•  The  planning  to  trace  and  map  all  PD  and  O&S  changes  to  the  baseline  from  initial 
identification  to  the  V&V  efforts. 
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4.4,  Technical  Baseline 

Describe  how  the  technical  baseline  maps  across  the  entire  WBS  in  support  of  system 
production  and  sustainment.  Include  a  copy  of  the  program  WBS  to  at  least  Level  3. 

Consider  the  following; 

•  The  program’s  technical  baseline  documentation  (system,  functional,  subsystem  and 
design  specifications,  and  standards)  and  alignment  between  the  WBS  and  the  technical 
baseline  documents  supporting  production  and  operations. 

•  The  program’s  production  and  sustainment  WBS  approach  down  to  the  hardware  and 
software  configuration  item  (Cl)  level. 

•  How  the  program  will  trace  top-level  requirements  (KPPs,  certification,  statutory, 
regulatory,  etc.)  and  key  safety  items  to  the  JCIDS  requirements  documents  (ICD,  CDD, 
or  CPD)  down  to  Cl  build-to  specifications  and  V&V  plans  (DT  and  OT). 

4.5,  Technical  Approach  to  Assess  Risk 

Describe  how  the  technical  approach  continues  to  address  the  manufacturing  and 
operational  hazards  (e.g.,  production  quality,  materiel  availability,  and  safety)  that  could 
jeopardize  achievement  of  program  outcomes. 

Consider  the  following; 

•  The  program’s  plan  to  measure  the  production  and  O&S  risk  (e.g.,  quality,  materiel 
availability,  and  ESOH). 

•  How  the  SE  process  continuously  assesses  production  risk  against  the  product  baseline. 

•  How  stakeholders  will  be  involved  continuously  in  the  assessment  of  risks  that  could 
jeopardize  achievement  of  program  outcomes  (e.g.,  quality,  materiel  availability,  and 
ESOH)  (see  DoD  4245. 7-M). 

5.  TECHNICAL  REVIEW  AND  AUDIT  PLANNING 

Describe  the  approach  to  establish  and  conduct  periodic  technical  reviews  and  audits 
throughout  the  program  life  cycle  and  specifically  for  Milestone  C  and  during  the  PD  and 
O&S  phases  (see  DAG  4.5.8).  Include  details  as  recommended  in  paragraphs  5. 1-5. 5. 

5,1,  Event-Driven  Technical  Reviews  and  Audits 

Describe  the  event-driven  technical  reviews  to  be  conducted  at  a  system,  subsystem,  and 
Cl  level.  Identify  program-specific  entry  and  exit  criteria,  defined  and  documented,  for  each 
technical  review.  Describe  how  the  program  will  conduct  event-driven  technical  reviews. 
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Describe  how  the  program  will  use  technical  reviews  to  establish  the  technical  baselines  in 
support  of  production  and  sustainment  requirements  (see  DAG  4.2.3.3,  4,3,  4.3.4.4,  4.3.5.4, 

4.4. 11 .2.  4.5.I.  4.5.3.  4.5.8.  and  4.5.7.4h 

Consider  the  following; 

•  The  program’s  approach  to  executing  event-driven  technical  reviews  (e.g.,  Production 
Readiness  Review  (PRR),  Operational  Test  Readiness  Review  (OTRR),  and  In-Service 
Review  (ISR)),  and  audits  (e.g.,  Physical  Configuration  Audit  (PCA))  and  to  ensure  they 
are  not  schedule  driven. 

•  The  planning  for  technical  reviews  (provide  a  schedule  of  all  remaining  technical 
reviews); 

-  The  number  of  technical  reviews  planned  and  to  what  WBS  level. 

-  The  technical  authority  (lead/chief  systems  engineer  and/or  functional  lead)  for 
entry/exit  criteria  for  each  review. 

-  The  technical  entrance/exit  criteria  for  each  review. 

-  The  readiness  for  conducting  each  review. 

•  The  timing  of  the  technical  reviews  and  audits,  tied  to  the  achievement  of  entry  criteria 
and  maturing  of  the  technical  baseline. 

•  How  the  PCAs  will  confirm  that  the  engineering  drawings,  specifications,  and  technical 
data  (including  commercial  off-the-shelf  documentation)  is  consistent  with  the  “as-buih” 
configuration. 

•  How  the  reviews  and  audits  will  support  other  key  programmatic  efforts/decisions  (i.e., 
transition  to  full  production). 

5.2,  Responsibility  for  Technical  Reviews  and  Audits 

Describe  who  is  responsible  for  the  overall  management  of  technical  reviews  and  audits. 
Consider  the  following; 

•  The  program’s  approach  for  oversight  and  conduct  of  technical  reviews  and  audits  (i.e., 
OTRR,  PCA,  ISR,  etc.). 

•  The  key  OPRs  and  stakeholders  involved. 

•  How  the  program  will  determine  readiness  for  technical  reviews  and  audits,  and  who  will 
be  responsible  for  making  the  decision  to  authorize  and  close  them  out. 

•  How  the  program  will  involve  the  technical  authority  (see  DAG  4.1.6). 

•  The  roles  and  responsibilities  of  those  involved  in  conducting  technical  reviews  and 
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audits,  and  the  procedures  they  will  use  to  conduct  and  close  outstanding  issues  from  the 
reviews  and  audits. 

•  The  approach  to  ensure  the  applicable  technical  products  (e.g.,  hardware,  software,  or 
process  specifications)  subject  to  each  review  and  audit  are  available  as  read-ahead 
material  to  the  appropriate  participants  (stakeholders  and  functional  leads). 

•  The  approach  for  integrating  the  outcomes  of  the  technical  reviews  and  audits  into  the 
program’s  plan. 

5.3,  Chairing  of  Technical  Reviews  and  Audits 

Describe  how  the  program  will  find  and  select  appropriate  chair(s)  for  the  technical 
reviews.  (Best  practice  is  to  use  independent  technical  authorities.)  Describe  the  role  of  the 
lead/chief  systems  engineer. 

Consider  the  following: 

•  The  approach  for  determination  and  selection  of  technical  review  and  audit  chairs. 

•  The  roles  of  the  PM,  lead/chief  systems  engineer,  and  the  technical  review  chair  and  how 
they  will  collaborate  on  technical  reviews,  especially  the  determination  of  readiness  for 
the  review  or  audit,  and  on  reporting  of  results. 

•  How  the  program  will  ensure  that  reviews  and  audits  are  conducted  according  to 
established  DoD  policy  and  engineering  preferred  practice. 

5.4,  Stakeholder  Participation  in  Technical  Reviews  and  Audits 

Identify  the  stakeholders  and  describe  how  the  program  will  involve  stakeholders  for  each 
technical  review  to  cover  all  production  and  sustainment  requirements;  KPPs;  statutory, 
regulatory,  certification,  and  V&V  requirements;  and  design  considerations  (e.g.,  realized 
reliability)  (see  DAG  4.1.2). 

Consider  the  following: 

•  How  appropriate  stakeholders  (e.g.,  users,  testers,  ESOH,  certifiers,  production  leads,  and 
design  and  sustainment  engineers)  and  representative  offices  for  specific  design  and 
sustainment  considerations  areas  are  involved  at  key  decision  points  (e.g.,  airworthiness 
certifiers  at  technical  reviews  and  audits). 

•  The  program’s  plan  to  involve  stakeholders  (e.g.,  users,  testers,  safety,  certifiers,  design 
and  sustainment  engineers)  by  organization  in  reviews  and  audits. 

•  How  the  program  office,  prime  contractor,  subcontractors,  and  relevant  industry 
representatives  will  participate  in  reviews. 
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•  The  membership  eomposition,  ineluding  the  method  for  nominating  and  approving  the 
ehairperson  and  membership  of  a  teehnieal  review  or  audit  board,  if  required. 

•  How  the  program  office  will  reconcile  resource  constraints  with  technical  staffing  needs 
for  the  reviews  and  audits. 

•  The  program’s  approach  to  involve  the  T&E  and  sustainment  communities  in  the  SE 
process  to  assess  risk  and  to  participate  in  technical  reviews  to  mature  the  technical 
baseline  (see  DoD  5000.2  E5.  Enclosure  5). 

5,5,  Peer  Participation  at  Technical  Reviews  and  Audits 

Describe  how  the  program  will  identify  peer  review  participants  for  the  technical  reviews 
and  audits  (see  DoD  policy). 

Consider  the  following; 

•  The  program’s  approach  to  addressing  peer  review  in  accordance  with  DoD  Policy  and 
how  peers  will  participate  in  technical  reviews. 

•  The  program’s  method  to  identify  the  subject  matter  areas  in  which  peer  insight  is  most 
relevant;  how  the  program  will  determine  the  technical  authority  to  access  suitable  SMEs. 

•  The  participation  of  senior  leadership  or  experts  in  functional  areas  (e.g.,  SMEs)  at  major 
reviews  or  at  other  key  decision  points 


6.  INTEGRATION  WITH  OVERALL  MANAGEMENT  OF  THE 
PROGRAM 

Describe  the  relationship  and  feedback  mechanisms  for  Milestone  C  and  during  the  PD 
and  O&S  phases.  Describe  key  sustainment  program  management  processes  and  strategies 
that  support  reporting  and  milestone  requirements  per  DoDI  5000.2  (see  E3.  Enclosure  3). 
Include  details  as  recommended  in  paragraphs  6. 1-6.5. 

6,1,  Program  Management  Planning  and  Control 

Describe  how  the  SE  approach  is  integrated  with  overall  program  management  planning 
and  control  efforts  across  production  and  sustainment  (e.g.,  the  AS,  WBS,  RMP,  IMP/IMS 
PESHE,  and  Earned  Value  Management  (EVM)). 

Consider  the  following: 

•  How  the  program  will  integrate  and  coordinate  SE  activities  across  production  and 
sustainment  phases  to  support  program  cost,  schedule,  and  performance. 

•  The  program’s  approach  to  linking  and  integrating  SE  with  other  management  efforts. 
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•  How  the  program  will  include  in  its  technical  planning  any  Government  Furnished 
Property  (e.g.,  test  ranges,  integration  laboratories  and  special  equipment)  needed  to 
support  production  and  sustainment,  and  how  the  program  will  link  this  planning  to  the 
IMP/IMS  (see  DAG  1 1.3).  Provide  a  copy  of  the  IMP/IMS. 

•  The  use  of  IMS  and  WBS  as  the  basis  for  any  production  or  sustainment  contract 
Integrated  Baseline  Review  (IBR),  cost  accounts,  and  EVM  implementation  (see  DAG 
11.3.1.3). 

•  The  use  of  SE  analysis  (e.g.,  M&S)  in  resource  estimation  and  availability  (e.g..  Special 
Tooling  and  Special  Test  Equipment  needed  for  manufacturing). 

•  The  program’s  approach  for  using  metrics  to  monitor  prime  and  subcontractor 
performance  for  impacts  to  cost,  schedule,  and  performance  (i.e.,  software  deficiency 
reports;  technical  performance  measures  (TPMs);  Critical  Technical  Parameters  (CTPs); 
measures  of  effectiveness  (MOEs);  measures  of  suitability  (MOSs);  measures  of 
performance  (MOPs);  and  Sustainment  KPP/KSAs  (i.e.,  materiel  availability,  materiel 
reliability,  ownership  cost,  and  mean  down  time)).  In  a  table:  the  metrics,  provider,  and 
reporting  frequency. 

•  The  use  of  SE  technical  planning  (analysis,  program  data,  and  decisions)  to  support  other 
program  activities  and  key  program  documents  requiring  MDA  approval  (see  DoDI 
5000.2  E3.  Enclosure  3). 

•  The  technical  planning  to  support  program  closeout  and  disposal. 

•  The  process  for  integrating  program  protection  with  SE. 

6,2,  Program  Manager’s  Role  in  Technical  Reviews 

Describe  how  the  program  manager  will  use  technical  reviews  to  manage  the  technical 
effort  and  to  contain  overall  production  and  sustainment  costs. 

Consider  the  following: 

•  How  the  PM  will  use  the  production  and  sustainment  technical  reviews  in  program 
decision  making. 

•  The  role  of  the  PM  in  preparing  for,  executing,  and  resolving  issues  from  the  production 
and  sustainment  technical  reviews. 

•  The  method  for  the  continual  and  accurate  identification  and  management  of  the  critical 
path  tasks,  production  rates,  and  quantities. 
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6,3,  Risk  Management  Integration 

Describe  how  the  SE  approach  is  integrated  with  the  program’s  risk  management  effort 
along  with  any  SoS  risk  consideration  (e.g.,  how  technical  reviews  provide  a  risk  assessment 
input  to  the  ongoing  manufacturing  and  hazard  risk  assessment  process)  (see  DAG  4.2.3.5, 

11.4:  RMG). 

Consider  the  following: 

•  How  the  program  will  integrate  the  RMP  (including  any  related  SoS  RMP)  with  the 
technical  approach  and  address  life-cycle  sustainment  considerations  (see  RMG  Ch  8; 
DAG  11.4). 

•  The  linkage  between  the  production  and  sustaining  SE  technical  reviews  and  the 
program’s  risk  assessment  process  (e.g.,  risks  of  successful  completion  of  the  next 
technical  review)  (see  RMG;  DAG  4.5.8). 

•  Identity  of  the  manager  for  the  risk  program  and  how  the  IPTs  will  apply  risk 
management. 

•  How  often  risks  are  reviewed,  by  whom,  and  how  risks  will  be  rolled  up. 

•  How  the  program  will  address  risks  and  issues. 

•  The  risk  management  tool  the  program  office  will  use  and  its  compatibility  with  the 
prime  contractor’s  tool. 

•  How  the  program  will  use  metrics  to  assess  program  risks. 

•  How  the  program  will  address  the  system  ESOH  objectives  and  risks,  as  outlined  in  MTT.- 
STD-882D. 

•  How  the  program  will  mature  enabling  technologies  and  their  associated  critical 
technology  elements  (CTEs)  and  processes  to  support  design  changes  during  production 
and  sustainment. 

•  How  the  program  will  accept  ESOH  risks  and  communicate  hazards  and  mitigations 
plans  to  the  user  and  operations  and  sustainment  organizations  (see  DAG  4. 3. 5. 3. 3). 

•  How  to  minimize  risks  during  the  transition  from  development  to  production  (see  DpD 
4245. 7-M). 

•  How  the  program  will  include  risks  and  SE  in  the  IMP/IMS  and  link  them  in  the  program 
life-cycle  planning  to  support  manufacturing  and  sustainment  (e.g.,  changes  in  proven 
materials,  special  processes,  subcontractors,  and  components). 

•  A  summary  of  key  SE  technical  risks,  including  interfaces  and  interdependencies,  with 
ratings  and  mitigation  plans. 
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6.4,  Test  and  Evaluation 

Describe  how  the  technical  approach  integrates  the  test  and  evaluation  (T&E)  planning 
during  the  PD  and  O&S  phases.  Describe  the  technical  approach  for  the  integration  and  test 
activities  (DT&E)  and  facilities  to  support  system  integration  and  verification  for  OT&E  and 
production. 

Consider  the  following: 

•  How  V&V  plans  will  be  integrated  in  the  SE  approach. 

•  How  the  overall  SE  technical  planning  integrates  with  the  TEMP. 

•  How  the  “test,  analyze,  and  fix”  activities  will  be  coordinated  to  resolve  deficiencies  or 
further  improve  the  system  prognostics  in  support  of  T&E. 

•  How  test  activities  integrate  with  OT&E  to  consolidate  test  requirements  where  possible. 

6.5,  Life-Cycle  Sustainment  Integration 

Describe  how  the  technical  approach  integrates  the  sustainment  planning  into  the  PD  and 
O&S  phases.  Describe  the  relationship  among  system  performance,  producibility,  materiel 
availability,  materiel  reliability,  ownership  cost,  and  mean  down  time  throughout  the  system 
life  cycle  (see  SUP  1.3). 

Consider  the  following: 

•  How  the  program  will  implement  SE  in  a  total  systems  approach  to  meet  the  mandatory 
sustainment  KPP/KSAs  (i.e.,  materiel  availability,  materiel  reliability,  ownership  cost, 
and  mean  down  time),  and  the  life-cycle  sustainment  enablers  (e.g.,  corrosion,  RCM, 
SIM)  (see  SUP  1.3,  M;  DAG  2.3.12.  4.1.3.  5.2.2:  DoDD  5000.1). 

•  How  the  overall  SE  technical  planning  integrates  with  the  Program  Manufacturing  Plan 
and  the  Product  Support  Plan. 

•  How  SE  technical  planning  addresses  sustainment,  obsolescence,  technology 
refreshment. 

•  Pre/Post  Initial  Operational  Capability  (IOC)  Supportability  Assessment. 

•  The  use  of  M&S  and  prognostics  in  support  of  production  and  life-cycle  sustainment 
objectives  (DAG  4. 5. 7. 5,  4. 5. 7.4). 
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6,6,  Contracting  Considerations 

Describe  the  SE  contracting  considerations  for  production  and  sustainment  (see  DAG  4,0, 
4,3;  Integrating  Systems  Engineering  into  DoD  Acquisition  Contracts). 

Consider  the  following; 

•  The  linkage  between  the  MDA-approved  SEP  and  the  contractor’s  SE  plan  to  establish  a 
fully  integrated  acquisition  and  sustainment  approach. 

•  SE  as  an  integral  part  of  future  contract  actions  (Requests  for  Proposal  and  Engineering 
Change  Proposals)  for  prime  and  subcontractors  to  support  production  and  sustaining 
efforts. 

•  How  the  program  will  evaluate  contractors’  software  plans  and  related  processes  (e.g., 
Software  Development  and  Sustainment  Plans)  and  integrate  those  plans  with  the  SEP 
and  processes. 

•  The  technical  basis  for  performance-based  payments  and  award  fees. 

•  The  technical  basis  to  provide  incentives  for  the  contractor  to  provide  effective  and  cost- 
effective  solutions  (e.g.,  design  for  production  efficiency  and  quality;  optimize  materiel 
availability  and  reliability  while  minimizing  cost  and  mean  down  time). 

•  The  technical  basis  to  provide  incentives  for  event-driven  reviews  and  technical  baseline 
management  across  the  program,  including  prime-to-prime  contractors  and  prime-to- 
subcontractors. 

•  How  the  program  will  assess  contractors’  capabilities  to  conduct  life-cycle  systems  and 
software  engineering  activities  for  security-related  practices,  foreign  ownership  control 
and  influence,  and  protection  of  Critical  Program  Information  (CPI). 
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Acronyms 

ACA 

Associated  Contractor  Agreement 

ACAT 

Acquisition  Category 

AS 

Acquisition  Strategy 

AoA 

Analysis  of  Alternatives 

AS 

Assessments  and  Support 

CAE 

Component  Acquisition  Executive 

CDD 

Capability  Development  Document 

CM 

Configuration  Management 

Cl 

Configuration  Item 

CONOPS 

Concept  of  Operations 

CPD 

Capability  Production  Document 

CPI 

Continuous  Process  Improvement 

CTE 

Critical  Technology  Element 

CTP 

Critical  Technical  Parameter 

DAG 

Defense  Acquisition  Guidebook 

DUSD(A&T) 

Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology 

ED 

Enterprise  Development 

ESOH 

Environmental  Safety  and  Occupational  Health 

EVM 

Earned  Value  Management 

ECA 

Eunctional  Configuration  Audit 

ICD 

Initial  Capabilities  Document 

IMP 

Integrated  Master  Plan 

IMS 

Integrated  Master  Schedule 

IPPD 

Integrated  Product  and  Process  Development 

IPT 

Integrated  Product  Team 
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ISR 

JCIDS 

JROC 

KPP 

KSA 

MDA 

M&S 

MOE 

MOP 

MOS 

MOSA 

MRL 

OIPT 

OPR 

OSD 

OTRR 

OUSD(AT&L) 

O&S 

PBL 

PCA 

PEO 

PESHE 

PM 

PRR 

PSC 

PSP 


In-Service  Review 

Joint  Capabilities  Integration  and  Development  System 

Joint  Requirements  Oversight  Council 

Key  Performance  Parameter 

Key  System  Attribute 

Milestone  Decision  Authority 

Modeling  and  Simulation 

Measure  of  Effectiveness 

Measure  of  Performance 

Measure  of  Suitability 

Modular  Open  System  Approach 

Manufacturing  Readiness  Eevel 

Overarching  Integrated  Product  Team 

Office  of  Primary  Responsibility 

Office  of  the  Secretary  of  Defense 

Operational  Test  Readiness  Review 

Office  of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology  and 
Eogistics 

Operations  and  Support 
Performance  Based  Eogistics 
Physical  Configuration  Audit 

Program  Executive  Office  or  Program  Executive  Officer 

Programmatic  Environmental,  Safety  and  Occupational  Health  Evaluation 

Program  Manager 

Production  Readiness  Review 

Preferred  System  Concept 

Product  Support  Plan 
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PSTL 

Program  Support  Team  Lead 

RCM 

Reliability  Centered  Maintenance 

RMP 

Risk  Management  Plan 

SDD 

System  Development  and  Demonstration 

SE 

Systems  Engineering 

SEMP 

Systems  Engineering  Management  Plan 

SEP 

Systems  Engineering  Plan 

SME 

Subject  Matter  Expert 

SOE 

System  Operational  Effectiveness 

SoS 

System  of  Systems 

SSE 

Systems  and  Software  Engineering 

STA 

System  Threat  Assessment 

TD 

Technology  Development 

TDS 

Technology  Development  Strategy 

TEMP 

Test  and  Evaluation  Master  Plan 

TES 

Test  and  Evaluation  Strategy 

TMP 

Technology  Maturation  Plan 

TPM 

Technical  Performance  Measure 

ERA 

Technology  Readiness  Assessment 

TRE 

Technology  Readiness  Level 

T&E 

Test  and  Evaluation 

USD(AT&L) 

Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics 

V&V 

Verification  and  Validation 

WBS 

Work  Breakdown  Structure 

WIPE 

Working-level  Integrated  Product  Team 
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